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: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Jeff Law <law at redhat dot com>, Richard Biener <rguenther at suse dot de>
- 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 16:54:48 +0000
- Subject: Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=softfail (sender IP is 10.152.2.59) smtp.mailfrom=hotmail.de; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB216226C00439A01515A3AA5FE4370@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.firstname.lastname@example.org> <AM4PR0701MB2162738A0964E4579175FE86E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com> <email@example.com>
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 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71876,
>>>> 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 for
>>>> a freestanding environment.
>>>> It is unsafe to return ECF_MAY_BE_ALLOCA, ECF_LEAF and ECF_NORETURN
>>>> from special_function_p, just by the name of the function, especially
>>>> for less well known functions, like "getcontext" or "savectx", which
>>>> 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 can
> 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