This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] may_alias attribute
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Osku Salerma <osku at iki dot fi>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 27 Jan 2002 12:58:01 +0000 (GMT)
- Subject: Re: [patch] may_alias attribute
On Sun, 27 Jan 2002, Osku Salerma wrote:
> > This should go in gcc.c-torture/execute ...
>
> Is there documentation describing what test should go in what
> directory? There were testcases for attributes in the gcc.dg directory
> and the dejagnu framework seemed easier than the one used in
> gcc.c-torture, so I put it there.
See the internals manual, in particular doc/sourcebuild.texi.
> Whether strict aliasing is on or not at -O2 has varied wildly between
> different GCC releases, and while unlikely that it will be defaulted
> to off in future releases, it's not impossible, and it doesn't do any
> harm having it explicitly set to on.
Providing this attribute makes defaulting it to off even more implausible.
> I'm not sure if gcc does alias analysis at all optimization levels,
> but to me it seems to be the safest choice to use -O2. Otherwise at
> some point in the future gcc might not do type-based alias analysis at
> lower levels, and someone breaks the may_alias attribute, and the
> testcase still works, so the problem isn't discovered.
gcc.c-torture/execute runs over multiple optimisation levels. This is
what you want for this test case; it is entirely appropriate to assert
that the attribute works both at optimisation levels with strict aliasing
and those without. If you want, add a note somewhere that if strict
aliasing if defaulted to off at all levels then -fstrict-aliasing should
be added explicitly to one of the sets of options c-torture runs over.
--
Joseph S. Myers
jsm28@cam.ac.uk