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

Richard Biener rguenther@suse.de
Thu Jul 21 07:09:00 GMT 2016


On Wed, 20 Jul 2016, Bernd Edlinger wrote:

> 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?

Hmm, but ECF_MALLOC doesn't guarantee non-NULL return.  I think the
two calls you patched simply shouldn't use the predicates (which
are misnamed as they check for _maybe_alloca_call_p).  Instead they
have to check for the respective builtins (BUILT_IN_ALLOCA,
BUILT_IN_ALLOCA_WITH_ALIGN).

Richard.

> 
> Thanks
> Bernd.
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)



More information about the Gcc-patches mailing list