Re: Internal representation of double variables - 3.4.6 vs 4.1.0

[Terry Frankcombe <terry at chem dot gu dot se>]

On Fri, 2007-03-09 at 10:33 -0800, Brian Dessent wrote:
> Terry Frankcombe wrote:
> 
> > After reading this, I went off looking for a gcc option enforcing IEEE
> > floating point behaviour, assuming gcc was like the Intel compilers and
> > by default sacrificed some exactness in the floating point model for
> > speed, even with no optimisation.  I could find none.  So, does gcc use
> > a well-defined and reproducible floating-point model by default?  If
> > not, can one turn on strict IEEE arithmetic?
> 
> That is not the problem.  The problem is that the intel x86 processor
> uses an internal 80 bit representation for 'double', which normally has
> only 64 bits.  This causes excess precision, which can appear as
> rounding errors in the ULP, but are not really errors, just
> misunderstandings of how IEE 754 works.  You can work around this with
> -ffloat-store but this incurs a speed penalty as it means temporary
> values can't be kept in registers but repeatedly stored and loaded from
> memory.  Or you can use SSE for fp math (-mfpmath=sse) instead of 387,
> if your architecture supports it.
> 
> See gcc bug 323 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323> for
> examples of this non-bug being reported over and over again dozens of
> times over the years.
> 
> Brian


So the short answers are "No" and "No", right?  ;-)

My understanding of -ffloat-store is that it only works when there's
actually a variable involved.  Is that right?

(I'm used to working with Compaq and Intel Fortran compilers, where you
can set flags that say, effectively, "Use a standard, well-defined and
portable floating point arithmetic model irrespective of what the CPU's
trying to do.")

Ciao
Terry