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

[Bernd Edlinger]

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?


Bernd.