This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc3 vs 176.gcc
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 09 Jan 2002 11:30:42 -0800
- Subject: Re: gcc3 vs 176.gcc
- References: <6D9A9370-0475-11D6-94EE-003065C86F94@apple.com>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
Dale Johannesen <dalej@apple.com> writes:
> The SPEC version of gcc (based on 2.7.2.2) contains this code:
...
> When compiled with -fstrict-aliasing (currently turned on by -O2), this
> doesn't
> work as expected on ppc Darwin (and probably elsewhere).
So, is there some reason why compiling with -fno-strict-aliasing is a
problem (other than the slowdown, of course)? I know that SPEC
specifically allows such flags to be used, and they don't count
against the optimisation flag quota for the base benchmark.
...
> so it really doesn't take too much intelligence to figure out they
> interfere, at least in this case.
This is a problematic case. In general, it means that the compiler
must have certain knowledge to correctly compile code; and so, it
means that we will start getting bug reports along the lines of "I
changed my source and now this code, which used to work, doesn't,
because GCC is not smart enough to deduce <X>, please fix it."
I think if you want to do this, a prerequisite should be that you can
document precisely what will work and what will not, from the user
point of view. The current rule (use unions) is expressed in the
documentation.
> 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.
Would this slow the compiler?
> 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.)
I believe this has been dealt with before, at great length, and the
answer is "no". I highly recommend going back and looking at the
previous threads in the mailing lists; I don't believe anything has
changed since then.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>