This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: criteria.html open issues
- To: "Albert D. Cahalan" <acahalan at cs dot uml dot edu>
- Subject: Re: criteria.html open issues
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Mon, 28 May 2001 01:02:12 -0700
- Cc: dewar at gnat dot com, gcc at gcc dot gnu dot org
On Mon, May 28, 2001 at 02:46:44AM -0400, Albert D. Cahalan wrote:
> Zack Weinberg writes:
> >
> > Reality injection: -fstrict-aliasing is enabled at -O2 in all
> > snapshots since 2.96, and will be in 3.0. It was turned off on the
> > 2.95 branch to give people more time to fix their code. It is our
> > understanding that most free software projects have either fixed their
> > code or wired in a -fno-strict-aliasing where appropriate.
>
> I do not believe that this is true. Most programs have code
> paths that are poorly tested. Error handling is a common case.
The version of 2.96 shipped with Red Hat Linux 7.x has strict aliasing
on at -O2. The system integrators went to considerable length to find
and squelch these bugs.
> Very few people are even aware that aliasing is dangerous.
> I work in a UNIX-centric environment with experienced OS
> developers, all of whom were surprised (and horrified) to
> see what the new compiler would do. Even more disturbing
> was that "volatile" wouldn't fix the problem.
I have zero sympathy. With the exception of kernel-level code, I have
never seen a -fstrict-aliasing -exposed bug that was not simply sloppy
programming.
We went around on this at great length in, IIRC, early 2000 - go
consult the archives.
[Note that I was, and am, in favor of the __norestrict__ feature that
was proposed back then, for code that genuinely does need to bend the
rules - but _not_ the "compiler intuits what the programmer 'must
have' meant" crock that was also proposed.]
> > except that -O2 should be a reasonable default choice (which it isn't
> > always; -O or -Os have been reported to be better under a rather broad
> > set of conditions). This is something I'd support addressing
> > comprehensively in the 3.1 time frame, it's much too late for 3.0.
>
> This sort of adjustment isn't even a code change AFAIK.
> You just tweak a spec file.
On the contrary, it is mostly determined by code (in toplev.c).
> > We'd want to look at tradeoffs between execution speed, executable
> > size, compiler speed, and ease of debugging; I'd suggest abandoning
> > the idea of 'levels of optimization' and instead tell the compiler
> > what you want to optimize for.
>
> Throw in: chance of miscompiling non-standard code.
> (so -O0 might let you get away with ++ on both sides...)
Disagree strongly. No mode should make special efforts to cater to
buggy code.
There is a place for options such as -ffast-math, where the programmer
wishes to sacrifice specific guarantees for the sake of speed;
however, it should always be very clear which those are and what the
consequences will be.
--
zw A man who has never gone to school may steal from a freight car, but if he
has a university education, he may steal the whole railroad.
-- Theodore Roosevelt