[PATCH] libcsupport: Workaround for GCC 5.1 and later

[Pavel Pisa]

Hello Chris and others,

On Wednesday 15 of July 2015 09:48:34 Chris Johns wrote:
> On 15/07/2015 4:50 pm, Sebastian Huber wrote:
> > I didn't file a PR, only asked on the mailing list. My impression is
> > that this is not a bug, but a feature that must be disabled by C library
> > developers.
>
> A compiler that optimises to a infinite recursive loop for code that is
> ok and not pushing any standards limit would seems like a bug to me.
>
> >> If the code being optimized is the function 'calloc', which it should
> >> know, then maybe this is not such a good idea to call itself.
> >
> > Yes, maybe this would complicate the compiler too much for a rare use
> > case, e.g. C library.
>
> I feel there is more pain with this issue to come for embedded users.

the compiler is innocent/documents this behavior. It is attempt to
really optimize code well. It is documented in the manual and you
can select if you want or do not want such optimizations of well
known standardized functions

  -fno-builtin
  -fno-builtin-<function>
i.e.
  -fno-builtin-calloc

in GCC manual
  https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Other-Builtins.html

I suggest to make code safe by specifying in RTEMS calloc source

  #pragma GCC optimize "no-builtin-calloc"

or

  #pragma GCC optimize "no-builtin"

or even better specify

  void *calloc(size_t nmemb, size_t size) \
    __attribute__ ((optimize("no-builtin")));


Check for syntax to be sure, may it be I have omitted
some comma or paretheses.

Best wishes,

                Pavel
-- 
                Pavel Pisa
    e-mail:     pisa at cmp.felk.cvut.cz
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/