This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Floating point trouble with x86's extended precision



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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]