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 Thu, 21 Jul 2016, Bernd Edlinger wrote:

> Hi,
> based on the discussion here, I have updated my patch again...
> This is the rest of the patch, which removes outdated function names,
> and creates built-in definitions for vfork, getcontext, savectx.
> These built-ins have the return_twice attribute but not the
> leaf attribute, because we do not really know, what these functions
> do.
> The reason for ceating the builtin functions is, that I would like
> to get a warning about conflicting builtin definition if someone
> accidentally picks the name of one of these less well known special
> functions, which are _not_ reserved names in most environments.
> I do not define builtins (without __builtin_ prefix) for setjmp and
> sigsetjmp because these are like wildcards, and they fall in the
> well-known category anyways.
> I still retain the handling of these functions in special_function_p
> because even in a free standing environment, returning
> ECF_RETURNS_TWICE is on the safe side.
> Is it OK for trunk after boot-strap and regression-testing?

As DEF_EXT_LIB_BUILTIN won't have any effect with -std=c99 for example
I don't think having the builtins helps much.  I think we have
this name-matching function for correctness purposes (and even my
local glibc doesn't declare [v]fork as returning twice nor does
the existing BUILT_IN_FORK btw).

So please simply leave special_function_p as-is, and simply just
return the for-correctness flags - ECF_RETURNS_TWICE and 

I think all callers but flags_from_decl_or_type should vanish
(calling that function instead).


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]