This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)
- From: Richard Biener <rguenther at suse dot de>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>,Jeff Law <law at redhat dot com>
- Cc: "jakub at redhat dot com" <jakub at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>,Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 20 Jul 2016 20:08:54 +0200
- Subject: Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB216226C00439A01515A3AA5FE4370@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.email@example.com> <AM4PR0701MB2162738A0964E4579175FE86E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com> <firstname.lastname@example.org> <AM4PR0701MB2162F81DBC64692DC5100927E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com>
On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger <email@example.com> 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:
>>>>> As discussed at
>>>>> we have a _very_ old hack in gcc, that recognizes certain
>>>>> 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 test.cc
>>> //extern "C"
>>> void *alloca(unsigned long);
>>> void bar(unsigned long n)
>>> char *x = (char*) alloca(n);
>>> if (x)
>>> *x = 0;
>>> g++ -O3 -S test.cc
>>> pushq %rbp
>>> .cfi_def_cfa_offset 16
>>> .cfi_offset 6, -16
>>> movq %rsp, %rbp
>>> .cfi_def_cfa_register 6
>>> call _Z6allocam
>>> movb $0, (%rax)
>>> .cfi_def_cfa 7, 8
>>> 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.