This is the mail archive of the gcc-patches@gcc.gnu.org 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, 2005-05-10 at 16:01 +0000, Joseph S. Myers wrote:
> On Tue, 10 May 2005, Daniel Berlin wrote:
> 
> > The first is the addition of the pointer no escape attribute, which is
> > used on functions to inform the optimizers that a pointer won't escape
> > the function we pass it to.
> 
> If this is meant to be user-visible then it needs documentation and 
> testcases.  If not, it should have a name which is not a valid C 
> identifier, as with the "no vops" attribute, so it cannot be specified in 
> source code.

I have no idea if it will be useful to be user visible, i guess so,
thinking about it.

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.

> 
> Diagnostics should now use %qE with an identifier in preference to %qs 
> with IDENTIFIER_POINTER.
> 
> I don't see the relation of the c-typeck.c change to the new attribute.  
> It needs its own testcase and justification.

The relation is that SPEC will stop compiling without it, because one of
the SPEC tests does:

free (foo, sizeof(foo));

Before the lib builtin, the implicit declaration would now be two
arguments, and everything would work fine.

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.


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




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