Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>If a code is written portably it shouldn't fail due to numerical differences 
>outside the precision of the declarations.

So you really think it's okay for any arbitrary reference to a variable
X to evaluate, at any given time, to X +/- a sufficiently small random
number?

That's what you're essentially saying -- that even IF (X .LT. X) should
potentially evaluate to .TRUE. on a random basis, which means even that
statement is not "written portably".  Further, you're saying that two
IF (X .LT. 0.) in a row should evaluate differently, if the difference
is due to bits 64-79 (so to speak) or, for single precision, 32-79, so
*that* statement is not "written portably".  For programs that *contain*
those statements to be "written portably", they must somehow cope with
the fact that the statements themselves may behave randomly.

Yet that contradicts any reasonable reading of ANSI FORTRAN 77, as far
as I can tell, which mandates that a *single* approximation is assigned to
a variable.  (It uses the singular, not plural, form of the pertinent
nouns.)

>I've noted also the correctness of Moshier's 
>suggestion that many spills are of loop-invariant quantities which are read 
>from static storage and thus a wider spill cannot contribute to accuracy.  
>It's a shame to have these spills hurt performance, and probably impractical 
>to distinguish them from those where there really are some guard bits to save.

Not impractical at all, though perhaps non-trivial for gcc as current
designed.  A compiler *necessarily* knows from where a value originally
came (static storage, or computed on-the-fly, e.g. in a register).
Whether it tracks that, I don't know.  One thing for sure: if the static
variable is *defined* with a new value initially computed as an 80-bit
result, then if that 80-bit result gets *any* visibility (i.e. if it is
not immediately truncated to the declared size of the static variable),
then, yes, any spill of that 80-bit result, *including committing the
value back to static storage for use by subsequent procedures*, must
preserve the entire 80 bits, to conform to ANSI FORTRAN 77, by my
(current) reading.

But, I didn't intend to re-propose 80-bit spills -- I withdrew my proposal
concerning that last December, and I'm sticking with my decision.  AFAIC,
"we" decided (overriding my concerns, despite the lack of any real
performance analysis showing that my proposal would be as bad as claimed if
implemented) to ignore FORTRAN standards compatibility in favor of the
ad-hoc consensus (which, *months* later, has yet to be clearly documented)
regarding how to write floating-point code for g77.

And defaulting to -mno-ieee, I've *also* already "swallowed" in terms
of what that does to the quality-of-implementation issue at a *design*
level.

What we're now beginning to discover is just how much that decision
adversely affected the quality-of-implementation at the *implementation*
and *packaging* levels -- to wit, random crashes depending on what
narrow range of numerics is involved, and confused users who don't
understand that they shouldn't go anywhere near a Fortran compiler
(much less write Fortran code).

And there's basically *nothing* I can do about this, even as g77 author
and de facto "project leader", since to effectively mandate what I believe
is the robust, properly-engineered design (which would include the
concept of *tolerances*, i.e. have the compiler support IEEE 754 in as
clean a way as possible so not only does Toon-style code work, but so
does independent spec-based testing, etc.), I'd have to either convince
the GCC team to switch everything over (which I will no longer attempt to
do) or re-do all their work in the form of a fork or new compiler (which
probably isn't worth attempting).

The issue now is, am I going to continue working on a compiler that an
extremely small percentage of the *Fortran programmer* population can
use effectively, given the decisions *already made*, and which I concede
will *not* be changed, concerning the use of truncating spills, defaulting
to -mno-ieee (without bothering to first architect, design, implement, and
document the underlying types throughout the infrastructure), and other
decisions that have been, and surely will be, made that are as wrongheaded
and short-sighted (as well as contradictory with each other) as I consider
these to be?

I expect I'll have made a decision by the end of this week, if not sooner.

After all, I've been *seriously* thinking about this issue since this
past December, and now regret that I didn't insist that we make robustness
of code generation and predictability of numerical results the #1 topic
of the Fortran BOF at LinuxExpo, since, in my view, that's the most
important decision vis-a-vis g77's future than anything else we discussed.

        tq vm, (burley)