This is the mail archive of the 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

Jim Wilson <> writes:

| Volker Reichelt wrote:
| > In the process of revamping the non-bugs section of the bug reporting
| > instructions I came across a problem with the excess precision of the
| > x86 FPU:
| This is a complicated issue.

[ ... excellent summary ... ]


| There is also another problem here that excess precision can cause
| problems even when it doesn't result in rounding errors.  This is the
| immediate case you are discussing with Brad Lucier.  Ideally, we
| should have no excess precision, and the testcase should work.
| However, due to the design of the x86, eliminating the excess
| precision is a burden on the compiler, and hurts performance, hence it
| is easier to ask users to program around it.

It might be easier for a compiler implementor to ask that. :-)
But it does not make getting around the problem easier.
In fact, it does put a HUGE burden on user programs AND it is
nowhere clear how users could do that reliably, methodically, in real


| As for solutions to the problem...
| 1) If you care about numerical accuraccy, don't use x86.


That is too harsh a statement.

| Seriously. AMD64 and IPF (aka IA-64) are OK, but IA-32 is not.  I
| realize this is impractical in most cases, but it is something that
| should be mentioned. If you must use x86 FP hardware then...

Somes compilers (e.g. VC++) seem to manage to get around those
problems on x86.  GCC should be able to do something.

| 2) Do FP arithmetic in the SSE registers via the -mfpmath=sse option.
| I haven't tried this myself, so I don't know how practical it is.
| 3) Set the FP reg rounding precision to 64 bits.  This has the flaw
| that you can no longer perform XFmode operations.  This is only a
| partial fix, in that we still have excess precision problems for
| SFmode operations.

Agreed.  But wouldn't it be better than current situation?

| 4) Try using -ffloat-store.  This works for some but not all
| programs. -ffloat-store forces user declared variables to be allocated

this is an advice I used to tell people routinely encounter this
problem with GCC on x86.  Alas, it does not seem to work properly, as
you noted below. 

| on the stack, and hence avoid the in register excess precision
| problems. However, temporaries are still allocated to registers, and
| can still cause rounding errors due to excess precision, so this is
| not a complete solution.


| 5) Fix the x86 backend to stop lying about availability of
| SFmode/DFmode operations, probably via an option, since this will
| reduce performance so much as to cause other problems.  This would at
| least give people the option of getting slow but correct code instead
| of the current fast but incorrect code.

I believe that is better than getting quick faulty behaviour.

-- Gaby

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