This is the mail archive of the
gcc-patches@gcc.gnu.org
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: Richard Biener <rguenther at suse 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 21:50:03 +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.53) smtp.mailfrom=hotmail.de; suse.de; dkim=none (message not signed) header.d=none;suse.de; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB216226C00439A01515A3AA5FE4370@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.2.11.1607201243320.30444@t29.fhfr.qr> <AM4PR0701MB2162738A0964E4579175FE86E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com> <8ecb18e7-7914-aa9f-3000-95fd0830c2a5@redhat.com> <AM4PR0701MB2162F81DBC64692DC5100927E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com> <BE30DF07-0E44-4591-9915-4220730E5D0E@suse.de>
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:
>>
>> 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.
>
On second thought I start to think that an external alloca function
might still work. And returning ECF_MAY_BE_ALLOCA just based on the
name could be made safe by checking the malloc attribute at the right
places.
With this new incremental patch the example
extern "C"
void *alloca(unsigned long);
void bar(unsigned long n)
{
char *x = (char*) alloca(n);
if (x)
*x = 0;
}
might actually work when -ansi is used,
i.e. it does no longer assume that alloca cannot return null,
but still creates a frame pointer, which it would not have done
for allocb for instance.
But the built-in alloca is still recognized because the builtin
does have ECF_MAY_BE_ALLOCA and ECF_MALLOC.
Is it OK for trunk after boot-strap and reg-testing?
Thanks
Bernd.
2016-07-19 Bernd Edlinger <bernd.edlinger@hotmail.de>
PR middle-end/71876
* fold-const.c (tree_expr_nonzero_warnv_p): Check for real built-in
alloca.
* tree-vrp.c (gimple_stmt_nonzero_warnv_p): Likewise.
Index: gcc/fold-const.c
===================================================================
--- gcc/fold-const.c (revision 238513)
+++ gcc/fold-const.c (working copy)
@@ -9018,7 +9018,7 @@ tree_expr_nonzero_warnv_p (tree t, bool *strict_ov
&& lookup_attribute ("returns_nonnull",
TYPE_ATTRIBUTES (TREE_TYPE (fndecl))))
return true;
- return alloca_call_p (t);
+ return alloca_call_p (t) && DECL_IS_MALLOC (fndecl);
}
default:
Index: gcc/tree-vrp.c
===================================================================
--- gcc/tree-vrp.c (revision 238513)
+++ gcc/tree-vrp.c (working copy)
@@ -1065,7 +1065,7 @@ gimple_stmt_nonzero_warnv_p (gimple *stmt, bool *s
lookup_attribute ("returns_nonnull",
TYPE_ATTRIBUTES (gimple_call_fntype (stmt))))
return true;
- return gimple_alloca_call_p (stmt);
+ return gimple_alloca_call_p (stmt) && DECL_IS_MALLOC (fndecl);
}
default:
gcc_unreachable ();