Re: Bug with g77 and -mieee on Alpha Linux

[craig at jcb-sc dot com]

>It seems to me that whatever we do we should have the capability to provide
>either an ieee or no-ieee set of libraries via multilibs.

Richard Henderson pointed out that, probably, the default for *libraries*
should be -mieee, with multlibbed -mno-ieee versions being provided only
*after* we find, via profiling or whatever, to be necessary to obtain
expected performance on real code.  (Well, I've enhanced the wording on
his position a bit -- hope I haven't misstated it as a result.)

>As to which mode should be the default, I'll leave that to y'all to sort out.

It's too late to make -mieee the default for 2.95, unless we significantly
slip the schedule.

I've seen too much evidence (in the form of bug reports) that codes
either hit ICEs or miscompile with -mieee that don't otherwise, or
at least they did in the past.  It stands to reason, in the abstract,
that -mieee makes for sufficient differences in FP code that latent
bugs might be exposed, certainly.

Therefore, the only way to offer a fully-working -mieee environment
in 2.95 is to *not* make it the default.

Which also means it won't get nearly as thoroughly tested in the future.

As with -fno-emulate-complex, when and if we ever try to make it the
default, we're therefore quite likely to find "show-stopper" bugs in
the release that is intended to accomplish that default change, due
to the upwards curve in worldwide testing of the default as we near
the actual release.

And, as with -fno-emulate-complex, unless one of *the* most important
purposes of such a release is to change the default over and let the
field shake out the bugs, the immediate response among GCC management
to the reports of those bugs, during the latter part of the release
cycle, will to be to change the default *back*, on the theory that
we'll avoid show-stopper bugs...

...thus leading to six months, a year, or two, of the default not having
been changed, therefore the option a *larger* portion of the user base
*wants* as the default to run their code *not* being tested.  (Though we
can, I suspect, reduce the testing differential by finding more and more
ways to a) test -mieee ourselves, b) tell everyone how committed we
are to supporting -mieee, and c) ask them to use it even when they think
they don't need it.)

In case anybody is wondering why I mention -fno-emulate-complex, the
issue here is, for me, again, *not* performance per se.  And I disagree
what ISTR Toon said about his making some kind of mistake by recommending
that it be turned on -- I think Toon did us all a service, which led
to us finding this new complex bug *sooner* than would otherwise had
been possible.

Yes, gcc back-end support for complex *was* known to be buggy, hence
all the work I did making -femulate-complex support work, which amounted
to putting all sorts of code into the g77 *front* end to transform COMPLEX
expressions into lower-level forms that back end understands as being
merely `float' and `double' expressions.  That happened years ago now, I
think.

But, once GBE complex support was *believed* to no longer be buggy,
and Toon recommended we make -fno-emulate-complex the default, I *jumped*
at the chance (for some arbitrary definition of "jump", I suppose; perhaps
I waited until I didn't see Jim Wilson or somebody say "whoa, no way is
that ready to try, even in the development version" ;-).

The reasoning I used was simple: while -fno-emulate-complex as a default
might destabilize *g77* over some period of time, it would accomplish
many of the same things I also believe having made -mieee, or 80-bit
spills, the default would have achieved:

  -  Much wider, "effortless", no-brainer-type testing of the "new" code
     (the GBE's complex support, new in the sense that it had recently
     been declared "finally ready" and yet had not been widely tested,
     not since g77 had -fno-emulate-complex as the (only) default and many
     bugs in the code thus exposed).

  -  Much wider *effect* of that additional testing, in that, while *g77*
     might expose whatever problems remained in the new code, the benefits
     of *fixing* that code would include *gcc*'s __complex__ support
     (which I suspect is rarely used) working better; perhaps more likelihood
     that GNAT might someday use it instead of doing its *own* transformations
     (a la g77, but using completely *different* code); ditto for gpc, aka
     GNU Pascal; and so on.

     That is, the more we commit to making the gcc *back* end (GBE) do
     complex arithmetic right, the more we are able to "centralize" our
     testing.  Right now, a complex bug found/fixed in GNAT doesn't help
     gcc, g++, g77, or gpc at all.  Thanks to -fno-emulate-complex being
     the default, thanks to g77 taking the "hit", we now at least know
     *gcc* has known bugs in *its* __complex__ support -- and a *real*
     bug-fix (not switching to -femulate-complex!) to g77 therefore
     fixes gcc as well.

So, while it's now clear that making -fno-emulate-complex the default
means we're going to have to swallow new bugs in g77 in the *short*
run, it's *still* the case that the *only* way we get long-term, solid
code-generation for complex arithmetic across *all* languages and *all*
systems we want to support is to bite this particular bullet.

Note that none of the above analysis takes either numerical-analysis
expertise *or* performance issues into account.  I believe it need not,
unless such issues threatened to *overwhelm* the other analysis.  (For
example, if we were now using the old, naive complex-divide method, and
people showed how that would break lots of code, and we couldn't just
switch that single method back by itself, then that might overwhelm the
factors towards making -femulate-complex the default.  Or if, say, we
discovered that although new LAPACK exposed the recently discovered complex
bug, we discovered that lots of *other* code that did *not* expose it
would suffer a 20x slowdown under -femulate-complex, that might overwhelm
in the other direction, towards swallowing/documenting the known bug.)

        tq vm, (burley)