Re: gcc 3.4 and Octave/lapack problems

[Dmitri A. Sergatskov]

John W. Eaton wrote:

> If we are going to use -ffloat-store for Fortran code because it
> produces better results (or at least results that are more likely to
> agree with what we would expect from 64-bit IEEE floating point
> arithmetic) then it seems to me that we should use it for the C and
> C++ code as well.  Or maybe you would prefer to have bad results
> faster?  :-)

I really do not quite understand all this, but here is some thoughts:

If I follow this logic then one needs to use -ffloat-store _always_.
Which means that gcc is broken. This is being disputed by
Jakub... It seems to me that the issue is only with one (or may be few)
of the lapack (fortran) files and this -ffloat-store is more a
workaround for the bug(?) in lapack code. In that case I do not
see why would we need this switch for C and C++. Perhaps we need to talk
to lapack people. I did file a bug to Redhat against lapack, but
have not heard back yet...

I still suspect that recent gcc with aggressive optimization
is not being ISO-complaint. (Apparently ISO C forbids  excess precision
after an explicit conversion to double (cast or affectation)).
But I cannot come up with the a simple sample code that demonstrates
this problem.

> jwe

Dmitri.
--