From maintainers-request at octave dot org Thu Nov 11 23:14:36 2004
Subject: Re: gcc 3.4 and Octave/lapack problems
From: "Dmitri A. Sergatskov" <dmitri at unm dot edu>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
CC: maintainers at octave dot org
Date: Thu, 11 Nov 2004 22:11:29 -0700

John W. Eaton wrote:
> On 11-Nov-2004, Dmitri A. Sergatskov <dmitri at unm dot edu> 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.
--