[PATCH] libcsupport: Workaround for GCC 5.1 and later

[Chris Johns]

On 15/07/2015 8:15 am, Peter Dufault wrote:
> 
>> 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.
> 

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