Re: Floating point trouble with x86's extended precision

[John Vickers <john at xza5 dot com>]

Heh.  I imagine you thinking something like "But I only
wanted to tidy the documentation..."

You might want to look at:

http://www.litho.ucalgary.ca/opt/SPRO/common/ug/goldberg1.doc.html#3377


There are several threads in the archives about these issues.

Geert Bosch produced an illustration of the precision issue back here:

http://gcc.gnu.org/ml/gcc/1998-12/msg00508.html

Some other threads:
http://gcc.gnu.org/ml/gcc/1998-12/msg00047.html
http://gcc.gnu.org/ml/gcc/1999-07n/msg00696.html
http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00466.html
http://gcc.gnu.org/ml/gcc/2002-06/msg00557.html


My take on it (I'm not an expert) goes:

- The worst thing is random excess precision.
- Double rounding isn't so bad.
- Setting the rounding mode to double still gives unpredictable
  and variable results.
- -ffloat-store is misnamed.  Stores to memory are not always
  necessary for correct assignment semantics.


More politically,

- If it halves the performance, that would be fine with me.
  Actually, only halving the performance might be a good
  achievement.
- x87 isn't going away aytime soon.
- GCC should default to sane FP on x87, and if people want to
  use broken fp on x87, they should have to positively request
  such behaviour.


Volker Reichelt wrote:
> On 21 Aug, Jim Wilson wrote:
> I got confused by your usage of the word truncated. In the example with the
> full FP stack you used "truncated" as a synononym for "rounded", right?
> And you wanted to say that after some intermediate results no rounding is
> done (no rounding to 64 bits that is, you have to round to 80 bits of course),
> and after some results (apparently correct) rounding to 64 bit is done.
>
> > It is the same fst/fstp instruction, so it is the same rounding.
> >
> > > But I think the difference between rounding and truncating is not the
> > > problem for the users.
> >
> > The problem isn't that the value is rounded.  The problem is that the 
> > value is rounded at unpredictable locations,
>
> Agreed. But that's not a bug IMHO.

When the unpredictable locations include the left-hand-sides of
assignments specified in the program text, this seems to me to fail
to comply with the language definition (for C) of assignments.

>>making it impossible to compensate for the rounding.
>
> What do you mean by "compensate"?
> I don't quite get what kind of goal you really want to obtain.

See the Goldberg paper cited at the top of this message.


Regards,

John.