[PATCH] Fix unsafe function attributes for special functions (PR 71876)

Jeff Law law@redhat.com
Wed Jul 20 18:42:00 GMT 2016


On 07/20/2016 12:30 PM, Bernd Edlinger wrote:
> On 07/20/16 20:08, Richard Biener wrote:
>> On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>>
>>> Yes. That is another interesting observation.  I think, originally this
>>> flag was introduced by Jan Hubicka, and should mean, "it may be alloca
>>> or a weak alias to alloca or maybe even something different".
>>> But some of the later optimizations use it in a way as if it meant
>>> "it must be alloca".  However I have not been able to come up with
>>> a test case that makes this assumption false, but I probably just
>>> did not try hard enough.
>>>
>>> But I think that alloca just should not be recognized by name any
>>> more.
>>
>> It was introduced to mark calls that should not be duplicated by inlining or unrolling to avoid increasing stack usage too much.  Sth worthwhile to keep even with -ffreestanding.
>>
>> Richard.
>>
>
> Apparently the MAY_BE_ALLOCA issue is worse than I ever thought...
>
> But I could not imagine that alloca can be anything else than a
> built-in.
>
> Is there any implementation where alloca is like an ordinary function
> call?
>
> I mean, does something like a function that allocates n bytes
> from the caller's stack frame work at all with any calling convention?
IIRC alloca was actually a normal call on some systems.  It'd use the 
current value of hte stack pointer to record the depth of the call chain 
and the objects allocated at that particular depth.  Calls to alloca 
would walk those chains to automatically deallocate objects that had 
been allocated in frames that had been subsequently popped.

Of course it was a heuristic and if you used alloca in fun1, then 
returned from fun1 and called fun2, then used alloca in fun2, you might 
expect objects allocated in fun1 to go away, but that didn't always 
happen (consider if fun1 & fun2 have the same stack size :(...

I don't know if any systems still implement alloca this way, but it was 
certainly was implemented as a normal call on some systems in the past.

jeff



More information about the Gcc-patches mailing list