Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>craig@jcb-sc.com wrote:
>
>> >The evidence on these lists prove that people are still forced to write
>> >programs without getting a decent course in numerical analysis.
>
>> Again, as I pointed out before, *I* have taken no "decent course
>> in numerical analysis".
>
>Nope, and it is not necessary for you to do so.
>
>[ Unless you want to take part in discussions like this, otherwise, 
>  you should just perform useful work on g77: ]

*My* original point was that choosing -mieee as a default would have
resulted in gcc/g77 support for the Alpha being, *today*, much further
along in terms of support for at least the industry-standard model of
floating-point.

Instead, we have inadequate, and probably overly buggy, support for -mieee
(no libraries compiled that way out of the box, and we sure aren't doing
enough testing of code with -mieee in effect to have much confidence that
simply changing the default wouldn't lead to all sorts of regressions,
ICEs, and so on), and buggy support (to say the least) for the default,
-mno-ieee.

In the meantime, you haven't answered my question as to why I should
be working on compilers, having taken no decent (well, no university-level)
course on compilers and having not read, well, I can't think of *one*
text on compiler design!

>I tried to express that to write useful numerical code one has to have
>knowledge of numerical analysis.

Fine.  Is it really your contention that not a single person who has
*ever* learned numerical analysis would use a wider range of IEEE 754
than you claim is all that needs to be properly supported?  (A range
you have yet to actually *specify*, I believe.)

>It is *not* sufficient to paper over mistakes made by people who didn't
>read their stuff just to get "the right answer".

So you consider implementing IEEE 754 properly to be "papering over
mistakes made by people who didn't read their stuff"??

>What a Fortran compiler should do is (IMHO) compile the source to the
>object code, using the latitude given by the Standard (i.e. SQRT: the
>result has a value equal to a processor dependent approximation to the
>square root of the argument).

In other words, it's okay if SQRT(16.0) => -1.5.  (Yes, folks, it's
true: the Fortran standard does *not* disallow that result.  I'm not
kidding.  Why Toon is suddenly resorting to the Fortran standard to
define what valid numerical behavior is, I don't know; frankly, in
comp.lang.fortran circles, it'd be a sign of incipient insanity, or
at least a indication that the person realizes he's losing the
argument.  But maybe that's no longer true; I gave up USENET about
six months ago.)

Sorry, Toon, but I've been working on Fortran compilers, and reading
comp.lang.fortran, long enough to have more of a clue than *that*.

Further, you have essentially argued that g77 need not even return *a*
value equal to that approximation, but may return *multiple* values equal
to that approximation, despite the very language you quoted.

That's what spilling 80-bit registers assigned to variables to 64-bit
or 32-bit temporaries *does* -- returns an 80-bit result and a 32-bit
result (say), allowing the processor to randomly choose which to use at
any given time, even when the result is assigned directly to a variable,
even if that variable (as assigned) is read only *once* in the user's
source code.

Getting back to the quality-of-implementation issue: I have always said
that it's ultimately okay for a Fortran processor to start WW3 if the
inputs don't conform, according to the standard.

But I *strongly* disagree with the idea that a *quality* implementation
starts WW3 only if the input happens to be between, say, 1E-60 and 1E-30,
or whatever the range of IEEE 754 single-precision denormals happens
to be.

That sort of implementation makes basic, solid, engineering practices like
testing and validation *much* less useful, because the behavior of
the underlying system changes wildly in the presence of out-of-range
values -- never mind whether the *code* running on top of it has any
actual *bugs* in it.

>If people want to get tighter control, there are two ways:
>
>1. Try to influence X3J3 to impose them.
>
>2. Use another language.

In which case, you won't mind one whit if -mieee and 80-bit spills are
made the defaults, since X3J3 doesn't impose *performance* constraints?

Well, it's about *time* you conceded that.

;-/

        tq vm, (burley)