This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bug with g77 and -mieee on Alpha Linux


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]