This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug with g77 and -mieee on Alpha Linux
- To: Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>
- Subject: Re: Bug with g77 and -mieee on Alpha Linux
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Sun, 11 Jul 1999 13:00:45 +0200
- CC: egcs at egcs dot cygnus dot com
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <199907110159.SAA22714@lotus.CS.Berkeley.EDU>
Edward Jason Riedy wrote:
>
> And Toon Moene writes:
> - Sure, when run on different architectures, they will give different
> - results. The crucial question, however, is: Are these differences
> - interesting ?
>
> Yup. When you're looking for the smallest eigenvalues, and they're
> clustered together, the differences are _very_ interesting. This
> is linked to the waterpipe remark: earthquake simulations. The
> smallest eigenvalues are the ones of interest (not recalling why
> at the moment, too tired). While _your_ code may not care about
> the nth place, these codes do. Trying to rely on data that's
> only as good as the input data deserves (which is a favorite
> phrase of Dr. Kahan's) can be very difficult when the best bounds
> on what the input deserves are still dodgy.
Well, if you have an error analysis that supports that (and I am sure
you have) then I am all with you.
> - Of course there are differences - but they're all meteorologically
> - irrelevant.
>
> That's nice. You're right, you shouldn't be relying on your own
> problem domain. There are others where it very much matters.
Touche'.
> - Heck - before the 60's, [...]
>
> Before the 60's, the idea of solving systems of equations with more
> than 6 unknowns was silly. The fact that von Neumann's error
> analysis was wrong was not widely known, according to Dr. Parlett.
> And the SVD didn't even exist (iirc).
Yep, after I wrote that (and reread it) it dawned on me that you can
reverse the remark I made: Getting better defined floating point
arithmetic permits different algorithms to be used.
> [on using extended precision]
> - But how do you reliably code that ? Going to assembler ? There is no
> - way to Standardly specify IEEE-754 extended precision arithmetic, yet.
>
> Who said anything about using IEEE-754 extended precision in hardware?
> The reference implementation of the XBLAS (not my project, but one
> of my advisor's) is using a software implementation. That system
> uses IEEE double (and won't work on x86s without forcing the CPU to
> round to double). It's also in C, for various reasons.
Sorry, I was jumping to conclusions, here - and down here:
> - > Yes, it could conceivably be possible to code around
> - > a lack of IEEE-754. The algorithms involved are complicated enough,
> - > thank you.
> -
> - Well, OK; that's a choice you want to make. I think it's rather obvious
> - that I don't like to live that dangerously.
>
> Pick your choices:
>
> * Live dangerously by relying on a standard that allows you
> to use, test, and debug a single version of your code, or
>
> * Live dangerously by littering your code with a thousand
> tests for various platforms, many of which are inaccessible
> to you, and try to test any problems by waving a dead
> chicken over the code and chanting ``please don't be too
> wrong'' a thousand times.
>
> These algorithms are _not_ simple. Go read Inderjit Dhillon's
> thesis on the new eigen routines in LAPACK. Then tell me if you'd
> even consider trusting an implementation that cannot be tested or
> verified with any sense of completeness. Good thing he didn't
> try to use g77 on an Alpha, or he'd still be working on it.
Well, as long as it is expressible in Fortran, we have no choice *but*
to support it. That means that if it doesn't work with the current
compiler, we should regard that as a bug.
> - It's a pity, but I agree that one should use a tool that does the job at
> - hand. If g77 doesn't cut it, that's fine with me.
>
> *boggle*
>
> I thought the idea was to improve it.
Hmmm, yes, that's what I mean - I didn't express myself very clearly:
If g77 doesn't yet do what you need, you should use another compiler for
the time being (and that's fine with me).
> Craig Burley is very correct. The relevant issue at hand should not be
> whether or not j. random code to be compiled is numerically correct.
> It should be whether or not the compiler is even known to produce
> correct code on all platforms where it is `supported.' Since no one
> even knows the definition of correct for g77...
Granted, but we often get bug reports where the code itself makes
assumptions that are simply not valid - e.g. the infamous "root-finder"
that compares the final value and its latest approximation for equality.
But you are right: If there is code for which there is a single correct
answer (or interval in which the answer should lie) then g77-compiled
code should provide that answer (an answer within that interval).
Cheers,
--
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html