This is the mail archive of the
mailing list for the GCC project.
Re: Floating point trouble with x86's extended precision
- From: John Vickers <john at xza5 dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>, wilson at tuliptree dot org, lucier at math dot purdue dot edu
- Date: Fri, 22 Aug 2003 15:33:59 +0100
- Subject: Re: Floating point trouble with x86's extended precision
- References: <200308212044.h7LKiIaX014443@relay.rwth-aachen.de>
Heh. I imagine you thinking something like "But I only
wanted to tidy the documentation..."
You might want to look at:
There are several threads in the archives about these issues.
Geert Bosch produced an illustration of the precision issue back here:
Some other threads:
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.
- If it halves the performance, that would be fine with me.
Actually, only halving the performance might be a good
- 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
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.