This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Floating point trouble with x86's extended precision
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jim Wilson <wilson at tuliptree dot org>
- Cc: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>, lucier at math dot purdue dot edu, gcc at gcc dot gnu dot org
- Date: 20 Aug 2003 23:27:02 +0200
- Subject: Re: Floating point trouble with x86's extended precision
- Organization: Integrable Solutions
- References: <200308201627.h7KGRHaX017733@relay.rwth-aachen.de><3F43E07B.5080502@tuliptree.org>
Jim Wilson <wilson@tuliptree.org> 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
codes.
[...]
| 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.
Yep.
| 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