Floating point trouble with x86's extended precision

[John Vickers]

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.