Re: Problem with function geev

>
> Ah, thanks for digging into this.  A little googling finds the LAPACK
> FAQ (http://www.netlib.org/lapack/faq.html) which indicates that dlamch
> (and its dependent routines dlamc[1-5]) should be compiled without
> optimization?  Can you compile dlamch.f by hand without optimization and
> see if that makes a difference for you?
>
> I'd really appreciate if you could, since I don't seem to have this
> problem on my linux boxes.
>

I recompiled with an unoptimized dlamch and this solved the problem as
well.  So now we have found multiple ways to solve the problem, and
this should do well for anyone wanting to use geev.  But in the
following I argue that we still haven't found the real issue.

I have to admit I'm afraid that this still treats the effect just as
the other modifications do.  I have linked the optimized/faulty
dlamch.o to a fortran program which calls on dgeev with non-tivial
arguments.  There was no problem with dlamch then (defeating my hope
to isolate the bug from the lisp fortran interaction).  Now, since the
same object file has an error depending on who calls on its
functions,I have to think the problem is in the caller not the object
file.

Even if the error were in the object file, I can't imagine
optimization could cause the error we're seeing.  I could understand
optimization causing a miscalculation of some machine parameters.  But
we are seeing the logical (C .EQ A) evaluating to false (or being
completely skipped), when it is in fact true.  If you tell me some
optimization would do this, I could believe you, but I don't think I
could ever trust optimization again.

Paul


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf