Re: Bug with g77 and -mieee on Alpha Linux

[Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>]

And Toon Moene writes:
 - 
 - What I *do* object to is people trying to mimic that in Fortran, hoping
 - that the Fortran Standard conformant evaluation of expressions and
 - IEEE-754 requirements don't clash.

You are quite right; that's the real problem.  Many people bemoan it.

However, there is a growing body of Fortran code (amazing statement,
even without the following quantifier) that thinks Fortran supports 
IEEE-754 in most ways.  And most of the compilers I can see (just
looked at the T3E (MIPSpro) docs, NAG's new f95 compiler's man
page, etc.) seem to be following that.

I'm not going to pretend that I know the differences between the 
Fortran Standard and IEEE-754.  I don't want to know the differences.  
(Just found out that F90 and F95 don't even agree on how to print
"-0.0".  Yech.)

Fortran seems to be moving in the IEEE direction, so I suppose the
real question should be whether or not IEEE floating point support
by default would _break_ functional codes.  I don't see how, but
of course someone at Berkeley is going to be supporting IEEE 
arithmetic.  ;)

 - I will read that.  Thanks for the pointer.

And if anyone else is interested, Dr. Kahan does have some other 
interesting FP texts under http://www.cs.berkeley.edu/~wkahan/ ,
including a rant on Java's arithmetic.  (No, I don't want to think
about gcj's IEEE-754 non-support.  ;) )  Dr. Fateman has some
vague lingustic notes from FP98 at .../~fateman/fp98/, but the
only part that may be of interest is in the korenD directory,
and it's not on the denorm topic.

--other--

BTW, in some FP experts' opinions (I don't qualify as an expert;
I'm relaying what's been said by actual experts around here) there's 
no such thing as fast code that produces incorrect results.  It's
incorrect code.  

And much of the code around here does _NOT_ fall into Toon's category.  
The FE codes very much have to deal with the nastier parts of the FP 
spectrum.  Some of the solutions are algorithmic (ignoring the 
vibrational modes of waterpipes), and others are numeric (using 
extended precision implemented on IEEE arithmetic during iterative 
refinement).  Yes, it could conceivably be possible to code around
a lack of IEEE-754.  The algorithms involved are complicated enough,
thank you.

However, you won't hear a peep out of most of the folks who write 
them.  They still think g77 is only f2c, and they all bought tuned, 
vendor compilers.  Many don't even know g77 still exists, or think
it died off (don't know it's now distributed with gcc).

g77's market around here right now is very, very, very small, 
consisting of folks who want a nice set of tools that lets them mix 
C, C++, and Fortran nicely, typically on clusters of Linux boxes.  
To be fair, gcc doesn't deal with the biggest systems in my immediate 
vicinity (Crays of various flavors), and won't link to vendor SMP-
capable BLAS on others (licensed libraries on Suns).  And other codes 
we want to play with (MUMPS, etc.) are in F90.  So my arguments can 
probably be dismissed; I'm not going to be using g77 for real work 
anytime soon.

Jason