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]: Pointer no escape attribute

On Tue, 10 May 2005, Daniel Berlin wrote:

> I'm not sure what you want in the way of testcases.
> Without the static vars analysis, there is no way to come up with
> testcases where this will give you different answers.
> If you want testcases that simply test that we handle the attribute,
> that is fine.

Tests of when the attribute is accepted and when it isn't, in gcc.dg.  
When the optimizations are added, tests of its effects.

> The relation is that SPEC will stop compiling without it, because one of
> the SPEC tests does:
> free (foo, sizeof(foo));

This has been reported to SPEC for them to provide a fixed src.alt?

> However, with the lib builtin, we now note that the use conflicts with
> the lib builtin's declaration, and hard error, even though the *user*
> hasn't done something wrong, we just changed the compiler.
> I asked on the gcc list what should be done about this, and was told to
> change convert_argments as i did, so that it was simply a warning.
> I'm happy to distill a small testcase for this.

Tests should include tests that if there is an explicit prototype 
declaration of the built-in function in scope then we continue to give an 
error: this special case should only be for when the only prototype is 
built-in and the in-scope declaration is implicit.  (Where we retain the 
built-in type if the new type is incompatible because changing the type of 
an existing built-in declaration causes problems, and we keep the built-in 
function rather than discarding it altogether as this is what's widely 
expected by code with implicit declarations or exit, abort etc..)

As far as I can see, it should be possible to test this change with an 
existing built-in function rather than relying on the new built-in "free".

> > In principle it seems to me this attribute should apply to function types 
> > rather than to function declarations.  Why is it being implemented as a 
> > decl attribute?  (If it is purely for built-in function then that would be 
> > one reason.)
> IIRC, Kenny just copied the way the malloc attribute is implemented.
> This attribute can be used exactly like the malloc attribute.

That some existing attributes only apply to function declarations but 
should apply to function types so they work for calls through function 
pointers is bug 3481.  The FIXME comments on noreturn and const attributes 
in c_common_attribute_table apply equally to malloc and pure attributes at 
least and maybe to others such as returns_twice.  So unless there's a 
substantial difficulty looking at the attributes on the type of a 
declaration (or more generally on the type of the function pointed to by 
the expression denoting the called function, which might not simply be a 
function name) it would be better to use a type attribute instead of 
adding to the collection of function attributes which should be changed to 
type attributes.

Joseph S. Myers      (personal mail) (CodeSourcery mail) (Bugzilla assignments and CCs)

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