[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