[PATCH] libcsupport: Workaround for GCC 5.1 and later

Peter Dufault dufault at hda.com
Tue Jul 14 22:15:50 UTC 2015


> On Jul 13, 2015, at 20:01 , Chris Johns <chrisj at 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




More information about the devel mailing list