This is the mail archive of the gcc@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]

Re: criteria.html open issues


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


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