This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


> Thanks
> Bernd.

Richard Biener <>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]