Re: gcc 3.4 and Octave/lapack problems

[Dmitri A. Sergatskov]

John W. Eaton wrote:
> On 11-Nov-2004, Dmitri A. Sergatskov <address@hidden> wrote:
>
> | BTW, according to  Jakub Jelinek
> | (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683)
> | 
> | <<<<
> | ...
> |       IMHO you want to open a bug against lapack (and/or octave) and request 
> that
> |       it be compiled in two versions on IA-32: -ffloat-store and -mfpmath=sse 
> -msse2
> |       (the latter for P4 & recent AMD CPUs).
> | ...
> |  >>>>
>
> If we have to know whether we are using a P4 or some recent AMD CPU
> (how recent, what does that mean?) to decide whether to use these

sse2 exists only in Athlon64 and Opteron chips. sse is single precision
and probably irrelevant.

> I would prefer to find a reasonable solution that will work on all
> platforms.  Those who want the absolute best performance (possibly at
> the expense of accuracy) can always build for their platform with
> special options.

I would argue that if some code requires compilation with a special flag to
produce expected results, then either code is broken or compiler is broken.
To be practical, it looks at the moment that recompiling lapack with
FFLAGS="-ffloat-store" solves the problem.
So my guess (since I cannot come up with a sample demonstration code) that
the code in question relies on (ISO?)
standards of double precision operation and gcc breaks it. If no C or C++
code in octave made those assumptions then we save without this option
to C and C++ compilers.

Those are just mine uneducated thoughts...

> jwe

Dmitri.
--