This is the mail archive of the
mailing list for the GCC project.
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 <firstname.lastname@example.org> 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
> 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,
Richard Biener <email@example.com>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)