Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>See "man ieee", and #include <machine/fpu.h>. When the program starts
>up, make a call to ieee_set_fp_control(IEEE_MAP_UMZ); , which sets the
>fp control to cause underflow to map to zero.

Ah, well, it's good people can do that if they want, though the arguments
against -mieee being the default included "because it catches bugs in code",
which, presumably, silently mapping underflows to zero won't.

My bigger problems with this whole line of argument are that, first, users
who *see* the IEEE format involved *expect* the full range, and, further,
that's what "everyone" supports on their hardware, so people code to that,
often without *thinking* they are.  The penalty for denormals should not
be program crashes, by default, since IEEE isn't (normally) implemented
that way.

(I assume -- incorrectly? -- that the FLT_MIN and related macros have the
correct values vs. for when -mieee is in effect.)

Second, when I think of how this issue intersects with Toon's *other* opinion,
that 80-bit spills are a waste of time that good programmers know how to
code around, I'm not sure I see *how* they can code around *both* defaults
portably.

To wit: how can a programmer be sure his code will *never* generate a
denormal (and, e.g., compare that denormal to some other value), if the
compiler can, as Toon says it must to "run fast" on machines like the IA32
class (and m68k?), compute *some* results to 80-bit precision and *others*
to 64-bit (or 32-bit) precision on a totally random basis?

Maybe no machine *today* has that combination of 80-bit computations
and a "fast" IEEE mode crashing on denormals (which Toon supports as the
default).  Though it's not hard to imagine Merced or McKinley might.

But, in theory at least, I can't see how a programmer can write code
that does something like

  IF (R - S .LT. .00001)

to test a tolerance *without* risking that R - S evaluates to a denormal,
because, while *mathematically* identical, and *computed* using identical
operations on identical operands, the *compiler* decided to compute R to
80 bits and S to only 32 or 64.

It's not like I feel like researching how to write floating-point correctly
at this point, given all the other stuff I have to do.

I just doubt it can be done, and *especially* that any coherent document
on *how* to do it is as freely available as g77, gcc, etc.

So maybe I'm wrong, but I throw this out in case other people, more
experienced with FP programming, can tell me so, or agree that, indeed,
writing portable code -- for machines that default in all the ways Toon
(and many others; he's just someone I *know* I can trust to care about
Fortran and related issues) wants -- is basically impossible, or at least
so hard to do right that a vanishingly small percentage of programmers
who, *today*, are writing code *intended* for such portability, code
that is being, or will be, *deployed*, are doing so *correctly*.

        tq vm, (burley)