This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)