Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>Some elder statesmen of Numerical Analysis really suffer from "All the 
>world is a Cray"-syndrome and never really accepted IEEE semantics.

Unfortunately, they never bothered specifying the FP semantics *they*
wanted from the rest of the industry and publishing that spec for me
(and other gcc developers) to work from.

That's what this really boils down to, I'm afraid: the anti-IEEE people
refuse to accept the notion that they should just put up with the
moderate slowdown they think IEEE mandates, but they don't offer any
*specification* for what it is they *really* want.

At least with IEEE 754, people like myself (who Toon now claims should
not even participate in these discussions!) can implement compilers to a
*spec*, write tests to a *spec*, even run industry-standard tests to
that same *spec*.  All without being experts in numerical analysis or
reading Numerical Recipes -- which gives them more time to be experts
in compiler development and read the Dragon Book.

In other words, I am now prohibited (by Toon) from discussing even whether
my *own* compiler implements floating-point arithmetic *correctly*, because
I'm not a numerical-analysis expert, because there's no *spec* for how it's
supposed to work, and, therefore, I must rely totally on the opinions of
others.

Whereas, when I *thought* g77 was supposed to faithfully work to *at least*
the (sometimes-less-than-ideal) "virtual" spec provided by the underlying
hardware, I *could* discuss whether g77 met that spec, because that spec
is usually formulated in language that doesn't require numerical-analysis
expertise to understand.  (E.g. long ago, when I read IEEE 754, I found
it pretty easy to understand.  Heck, I was helping hardware developers
debug and diagnose floating-point hardware for a mini-supercomputer back
then.  All without numerical-analysis expertise.  I left the company not
long after the VP of Engineering told me there was no way the company
would fix already-deployed systems that I discovered miscompared 64-bit
values that differed starting in bit 32 -- once I learned that the people
at the top didn't care to ensure the machine could be part of an overall,
robust system, I didn't hang around long, despite being paid far more
[salary] than I'm being paid now to work on g77 [nada].)

Now, in the last six months, we've learned (all from Toon, mind you, one
of *the* most respective voices in the OSS number-crunching community, and
for good reason), that:

  1. Even if Fortran says a computation evaluates to a single approximation,
     a good compiler ignores that (as mere "advice") if evaluating multiple
     approximations leads to faster code.  After all, good code is
     (somehow -- I have yet to see any clear, correct recipes as to how to
     make this happen) insensitive to that behavior.

  2. No good compiler bothers special-casing values in the IEEE 754 denorm
     ranges.  That's because no good code computes values in those ranges.
     Therefore it's okay if values in those ranges cause undefined results,
     from crashing to returning really *huge* numbers instead to whatever.

  3. No good compiler should bother worrying about merely *tiny* numbers that
     are "close" to IEEE 754 denorms, such that comparing mathematically
     identical values that are computationally different due to #1 might
     produce denorms.

Particularly of note is that rule #3 sprang into existence, to my view,
only after I'd pointed out the apparent contradiction between rules 1 and
2, which apparently were formulated months, or years, ago.  I.e. rule #3
didn't exist until sometime yesterday.  If anyone believes otherwise,
please email a URL showing where it was publicized, I'd love to see what
I'm missing!

I'm no longer interested in trying to write a compiler to a non-existent
specification, so I've pretty much decided to stop bothering, and go find
something else to do -- which will almost certainly involve software work
only to the extent that the project is run by someone who actually
understands total quality engineering for large-scale projects, which
appears to *not* be the case for GCC (or GNU or even Linux).

I mean, Y2K is a stupid problem made with exactly the same mind-set that
is being employed here: "nobody should ever deploy this system beyond 1999,
that is just *way* too far in the future" is, from a total-quality
standpoint, nearly indiscernible from "nobody should ever compute a value
smaller than 1E-15".  The concept of "degrade gracefully", designed into
IEEE 754 (for better or for worse), doesn't exist for people with this
mind-set -- they prefer "degrade randomly, as long as it still runs fast"
or something like that, and are under the delusion that their approach
works for large-scale systems (which includes basically any project that
depends on a compiler as large and complex as gcc/g77, IMO) developed by
a large number of people with varying sorts and levels of expertise.

Seems to me I have better things to do with my time, experience, and
expertise than put a nice sheen (good docs, rewritten g77 front end,
whatever) on a project where the people in charge can't wait to add the
*next* Y2K-like bug.  However nicely I pave the road, and decorate it with
flowers, it'll still be a road to hell, and it doesn't help much that I
can claim my particular *segment* of it doesn't actually get you there all
by itself.

        tq vm, (burley)