This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger <> wrote:
>On 07/20/16 18:20, Jeff Law wrote:
>> On 07/20/2016 09:41 AM, Bernd Edlinger wrote:
>>> On 07/20/16 12:44, Richard Biener wrote:
>>>> On Tue, 19 Jul 2016, Bernd Edlinger wrote:
>>>>> Hi!
>>>>> As discussed at
>>>>> we have a _very_ old hack in gcc, that recognizes certain
>functions by
>>>>> name, and inserts in some cases unsafe attributes, that don't work
>>>>> a freestanding environment.
>>>>> It is unsafe to return ECF_MAY_BE_ALLOCA, ECF_LEAF and
>>>>> from special_function_p, just by the name of the function,
>>>>> for less well known functions, like "getcontext" or "savectx",
>>>>> could easily used for something completely different.
>>>> Returning ECF_MAY_BE_ALLOCA is safe.  Just wanted to mention this,
>>>> regardless of the followups you already received.
>>> I dont think so.
>>> Consider this example:
>>> cat
>>> //extern "C"
>>> void *alloca(unsigned long);
>>> void bar(unsigned long n)
>>> {
>>>    char *x = (char*) alloca(n);
>>>    if (x)
>>>      *x = 0;
>>> }
>>> g++ -O3 -S
>>> result:
>>> _Z3barm:
>>> .LFB0:
>>>     .cfi_startproc
>>>     pushq    %rbp
>>>     .cfi_def_cfa_offset 16
>>>     .cfi_offset 6, -16
>>>     movq    %rsp, %rbp
>>>     .cfi_def_cfa_register 6
>>>     call    _Z6allocam
>>>     movb    $0, (%rax)
>>>     leave
>>>     .cfi_def_cfa 7, 8
>>>     ret
>>> So we call a C++ function with name alloca, but because
>>> special_function_p adds ECF_MAY_BE_ALLOCA, the null-pointer
>>> check is eliminated, but it is not the builtin alloca,
>>> but for the C++ front end it is a pretty normal function.
>> Clearly if something "may be alloca", then the properties on the
>> arguments/return values & side effects that are specific to alloca
>> not be relied upon.  That to me seems like a bug elsewhere in the
>> compiler independent of the changes you're trying to make.
>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

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.


>> Jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]