Re: sparc vs lapack

[craig at jcb-sc dot com]

>Agreed.  But the support for __complex__ is badly broken, even for simple
>stuff.  In a nutshell, it falls on its face anytime one tries to get the
>components out of a hard register that is wider than the component.

I'm still wondering how those components got *in* that hard register.  ;-)

(Reminds me of the old "Fernwood/America Tonight" show, where host Martin
Mull responds to the co-host Jerry's(?) complaint, while jammed into a phone
booth with a very large woman for some reason, "she tore my underwear!" with
the deadpan "she shouldn't have been wearing it!".)

>I'm not necessarily talking about interfacing to C/C++ code.  Think about
>libraries that you might get from a 3rd party that were compiled with some
>other non-GNU Fortran compiler.

Right, but, I just want to beat this dead horse again: problems in *this*
scenario would *not* be regression.

That is, gcc's and g77's "relationship" to such libraries would get no
*worse* in this release than in any other since, well, forever.  (I won't
go into the details as to why that is -- my previous emails explain them,
I think, if they're needed by anyone.)

So I assume you're worrying about the *new* users who flock to 2.95 in droves,
having waited to use gcc/g77 (at least for some new codes of theirs) until
the egcs/gcc split delivered a clear winner, or something.

>I think our job now is to decide between:
>  a. Change the default for 64bit targets that pass parameters in registers.
>
>  b. Not change the default and abort if the compiler detects an access to
>     the high part of complex value in a hard register.

I prefer the latter, but don't understand the issues (especially the
implementation) well enough to have a clear picture of the various
risks.

I think the likely-case scenario, if we choose b), is that we abort only
on *some* codes, which we tell people to then try compiling with
-femulate-complex to see if that works.  (Can we put such a message
into the ICE itself?  Please?  Please?  ;-)

If compiling with -femulate-complex works, great, otherwise, we've uncovered
a bug or even a regression.  But with option a), that means we've uncovered
it as a *default* and we're probably hearing about it as a bug report against
the release, perhaps even from a user who swears it "worked fine" when
he dutifully tested the prerelease version of g77 over the last several
months using the same codes.

Whereas, with option b), we still have a bug, but we *knew* we might have
them anyway.  (We make sure it's not *too* embarrassing/undocumented that
we have easily-fixed bugs, by testing LAPACK with -femulate-complex on
systems that don't pass it without.  If it fails on a target and we can't
quickly fix it, we just document that -- unless we decide we need to hold
up the release to fix it.)

And, with option b), we don't have to tell people "hey, remember all that
testing you did of our prerelease g77 from April through early July?  well,
we kinda threw that out the window, but you can get a reasonable
facsimile of what you were testing by compiling everything with
-fno-emulate-complex, which might help you avoid latent bugs in code
generation, whether they generate ICEs or bad code".

Again, that's assuming you are confident that option b) catches the
problematic cases vis-a-vis g77.

        tq vm, (burley)