Re: gcc3 vs 176.gcc

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 8 Jan 2002, Dale Johannesen wrote:

> via (int*)), so gcc3 is within its rights here.  Still, it looks pretty 
> silly
> for gcc3 to be unable to build an earlier version of itself, and I want to
> see if there's sentiment for doing something about it.

The answer is to get SPEC fixed somehow.  If doing a normal build of old
GCC with new GCC, you'd use "make bootstrap" and so new optimisations
would be irrelevant.

> Could we change the aliasing check as follows?  First check for whether two
>   memrefs are accessed off the same register(s); if they are, we know at 
> once
>   whether the memrefs interfere or not (depending on the offsets).  Only if
>   the result of this check is indeterminate do we look at the aliasing info.

You should of course give a warning in such a case, if we know they
conflict and type-based aliasing says they don't.  Read all the post-2.95
discussions about possible such warnings.

> Could we decouple -fstrict-aliasing from -O2?  (Apple may well do this 
> internally
>   in any case, since technically incorrect casts like the one above seem to 
> be
>   fairly common in existing code.)

Did the SC ever consider this, like they were meant to before 3.0
(according to the release criteria)?  It's been long enough since 2.95 for
most software to have found the problems when using 2.95 and either
started using -fno-strict-aliasing (Linux, Perl) or fixed the problems
(GCC itself, glibc).  I don't think we should now penalise working code
when built with autoconf's default options to allow for broken code whose
maintainers have been ignoring GCC developments for years.  
(-fstrict-aliasing was already present, defaulting to off, in EGCS 1.1.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk