🚀 go-pugleaf

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>chased@rbbb.Eng.Sun.COM (David Chase) writes:
>> I will suggest that you have no evidence, only anecdotes,
>> for the alleged pervasive bugginess of optimizing compilers.
>
>He says this while another comp.lang.c poster complains about an
>optimizer bug, while I find that a new optimizer crashes on an empty
>loop, and while someone else sees an optimizing Fortran compiler that
>still produces incorrect code for overly complex control structures.

That's still just anecdotes.  You've found what, maybe one bug per
compiler?  That's not pervasive.  Note the nature of the bugs --
you've got one bug in a beta-test compiler (GCC -- this is not a slam
on GCC either; most people don't release their beta compilers for the
world to tinker with), one bug that, though annoying, won't cause you
to go debugging down a rathole, and one bug that will actually cause a
programmer to waste time.  I'd call that last bug serious.

I've never claimed that optimizers were bug-free, but I will claim
that the bug rate is acceptably low for the improved performance that
they offer, especially if compared with other methods of obtaining
that performance (i.e., hand-tweaking of assembly language,
source-to-source transformations).  People make mistakes.
Furthermore, in the sad event that a compiler has a bug in it, I can
often write down description of the bug and put it on my list of
things to avoid/watch for(/repair?) in the future.  Human beings,
however, are creative, and make *new* mistakes.

People should do the optimizations that compilers cannot hope to get
(i.e., selection of appropriate algorithm), and leave the repetitive
twiddly stuff for compilers.  Furthermore, even after extensive
application of hand-optimizations, optimizing compilers can still
yield performance improvements by performing optimizations not
expressible (within bounds of tedium) in the source language (note
that some of these optimizations still fall into the category of
"aggressive" optimizations -- e.g., movement of non-volatile loads and
stores for scheduling, software pipelining, tail-call elimination).

Arg.  I'm sure I sound like a broken record, but I'm sure glad I
stayed out of the pointer-and-arrays fiasco.

David Chase
Sun Microsystems