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: p...@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
