> 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.
Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
