On 15/07/2015 8:15 am, Peter Dufault wrote: > >> On Jul 13, 2015, at 20:01 , Chris Johns <chr...@rtems.org> wrote: >> >> On 14/07/2015 4:20 am, Joel Sherrill wrote: >>> >>> >>> On 7/13/2015 1:06 PM, Sebastian Huber wrote: >>>> Yes, this option sounded like the right way to fix it, but... >>>> >>>> https://gcc.gnu.org/ml/gcc-help/2015-03/msg00093.html >>>> https://gcc.gnu.org/ml/gcc-help/2015-03/msg00094.html >>> >>> Ouch! That is a big red flashing sign which says stay away! >>> >>> And to Gedare's point of raising this as a PR, it is just >>> an optimization side-effect more than bug. >>> >>> I wonder if this could impact any code in newlib? It should >>> have the same issue with the default calloc(). And maybe >>> some other routines like the string and mem* ones? >>> >> >> For the record can someone please explain why 'calloc' broke with gcc 5 >> on ARM in the first place ? >> >> What is the code construct in that specific function [1] that is causing >> the issue in the first place ? It seems a common type of idiom and I am >> sure it must exist in user code. >> > I’m guessing the optimizer is recognizing that the code sequence used to > implement calloc() matches the definition for the built-in function calloc() > and so changes it to a call to calloc(). That won’t be an issue in (most) > user code. >
Agreed, so why is this not a bug in gcc ? Sebastian, is this logged with gcc ? 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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
