Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love <d dot love at dl dot ac dot uk>]

>>>>> "JCB" ==   <craig@jcb-sc.com> writes:

 JCB> Hardly.  it's a *precise* description of what Toon constantly
 JCB> advocates: the idea that any program written to exploit the full
 JCB> range of IEEE 754 *values* (not even using *features* like
 JCB> signalling NaNs, trapping on inexact, etc.) is inherently
 JCB> *wrong*,

I don't recall so, though perhaps that's what he thinks; it's
obviously silly.  I can say that when I maintained a system used by a
lot of the world's protein crystallographers, such a program would
have to have been considered broken because it wouldn't run on 3
architectures required (one of which is probably now a non-issue, but
not the others).  Thus, for instance, I wouldn't have been able to use
Knuth's currently recommended random number generator.

For historical reasons IEEE conformance is basically irrelevant to the
code, for large values of `the code'.  That doesn't mean it's
worthless generally.

 JCB> Yet, programs *aren't* working, when compiled with g77.  Toon says
 JCB> they're buggy programs

Most of the time they are, and I say ``read `Working Programs'''.  The
one in question is likely buggy, given that it's
optimization-dependent, regardless of the problem printing the
results.

 JCB>  -- my impression is, users are concluding *g77* is buggy, in
 JCB> droves.  

They've always done so.  To minimize it, you'll want defaults taken
from `Working Programs', and then they'll say it's just slow.

 JCB> I'm coming to the same conclusion myself, that g77 is fatally
 JCB> buggy, by design, because of its refusal to offer even basic,
 JCB> predictable behavior.

I've certainly wanted a framework for controlling the FP behaviour
across platforms as consistently as possible, as have other users, but
the work I did on it was rejected and it was clear that working on the
f2000 features would be a waste of time.  Complete consistency across
even IEEE-ish targets is surely doomed, though.

 JCB> So other systems crash on overflow (instead of generating Inf)?

Of course they do, though they're decreasing in importance in my game,
if you mean the basic hardware.  However, I'd almost always want to
set up the FP system on an IEEE box to do that anyway to find the
bugs.  I distributed the crystallographic suite that way for all the
systems I knew how.  I got grief from users who seemed to want bogus
output, but I fixed plenty of bugs.

 >> They might, but that's not what the actual behaviour is here;
 >> underflows give zero.  Not that experimental results seem to carry
 >> much weight.

 JCB> No, 

Please spare me the diatribes when I report how things actually behave.

$ uname -a
OSF1 pxsv6.dl.ac.uk V4.0 1091 alpha
$ cat >z.f
        a=exp(-100.)
        print *, a
        end
$ f77 -O0 -ieee_with_no_inexact z.f  && ./a.out
  3.7835059E-44
$ f77 -O0 z.f && ./a.out
  0.0000000E+00
$ g77 z.f && ./a.out
  0.

 JCB> the *actual* behavior appears to be that, 

I refer to the behaviour I actually observe.  I can now check how an
Alpha works rather than just being told I don't understand it without
useful explanation.

 JCB> depending on where the number comes from, a denormal *crashes* a
 JCB> "working" program, while other sorts of underflow (below the
 JCB> denormal range, I expect) don't.

If you generate a subnormal-style bit pattern either directly or from
separately compiled -mieee code and operate on it in -mno-ieee code,
yes, you get a crash.  The issue with libI77 is trivially fixed.

 >> Note that gcc's default is the same as Digital's.

 JCB> If only that were the case, we'd have few of the problems we
 JCB> have now.

I'm using the Digital compiler and I checked before saying so.  They
both default to the non-IEEE mode, as documented.

 JCB>   Digital Fortran offers a fully-working environment based on what
 JCB>   we call -mno-ieee *and* offers a fully-working environment based on
 JCB>   what we call -mieee as well.  It happens to offer the first as a
 JCB>   default.

 JCB>   g77 offers neither choice.

I don't understand what `fully-working' means -- bug free?  (g77
clearly doesn't provide a fully-working environment on any system;
particularly because debugging doesn't work properly.)

The DEC default is to crash on overflow, for instance, which it sounds
as though you think is wrong.  I get a segv from attempted i/o of a
subnormal in default mode compiling with it.  I've verified that gcc
and g77 pass paranoia perfectly with gcc -mieee and appropriately
multilibbed libg2c.

Given the value of `offers neither choice', perhaps someone can sort
it out.  I'd fix and test the multilibbing if I thought it stood a
better chance of being accepted than similar stuff I've wasted time
on.

 JCB> Remember, my original statement was to the effect that -mno-ieee
 JCB> as a default was a poor choice because we didn't bother to
 JCB> properly implement it, whereas, at least with -mieee, we'd have
 JCB> had plenty of *existing* code (coming from other,
 JCB> IEEE-754-conforming, environments), such as library routines,
 JCB> test suites, and so on, to just "plug in" for ordinary use.

I don't understand what that's about.  How is it not properly
implemented (modulo general bugs with 64-bit targets and other bugs
not directly related to the fP model)?  Why the confidence that -mieee
is properly implemented in contrast?  (libf2c was developed on VAXen,
presumably along with Berkeley libm stuff originally.)

 JCB> The assertions so far amount to "but any code that doesn't work
 JCB> with g77 is inherently broken", or some Gatesian approximation
 JCB> thereof.

I fail to see how, at least from me.  g77 on Alphas has clearly had
serious problems unrelated to IEEE FP behaviour.

I don't get the rant about DEC's FP models.  VAX FP is the major
reason that most code doesn't require IEEE conformance, for historical
reasons if nothing else.  If DEC decided (for such reasons?) that that
a non-IEEE default was appropriate, and they're so good at such
things, I'm baffled why it was so wrong for kenner to follow the
lead.