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


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