Inconsistent floating point result when using G++ 3.3.6 with option -O0 or -O1 separately

Inconsistent floating point result when using G++ 3.3.6 with option -O0 or -O1 separately

[Deng Shi]

 

-----Original Message-----
From: Deng Shi 
Sent: 2006年7月13日 10:37
To: 'gnu-help@gnu.org'
Subject: Inconsistent floating point result when using G++ 3.3.6 with option -O0 or -O1 separately

hi expert,
I found our application tool gave the inconsistent floating point result when using different optimization level -O0 or -O1.
Even if I used -O1 plus all the disabling options which includes in -O1, like -O1 -fno-merge-all-constants -fno-zero-initialized-in-bss -fno-function-cse -fno-keep-static-consts -fno-omit-frame-pointer -fno-merge-constants -fno-loop-optimize -fno-cprop-registers -fno-if-conversion -fno-if-conversion2 -fno-delayed-branch -fno-guess-branch-probability -fno-defer-pop -fno-crossjumping -fno-thread-jumps " which command line setting should be equal to -O0, but I still didn't get the consistent result. 
I wonder whether there is any additional optimization enabled by -O1 for C++ language which is not documented in GCC manual?

Is there anybody helping me?

Best regards!
Deg

Re: Inconsistent floating point result when using G++ 3.3.6 with option -O0 or -O1 separately

[Jim Wilson]

> I found our application tool gave the inconsistent floating point result when using different optimization level -O0 or -O1.
> Even if I used -O1 plus all the disabling options which includes in -O1, like -O1 -fno-merge-all-constants -fno-zero-initialized-in-bss -fno-function-cse -fno-keep-static-consts -fno-omit-frame-pointer -fno-merge-constants -fno-loop-optimize -fno-cprop-registers -fno-if-conversion -fno-if-conversion2 -fno-delayed-branch -fno-guess-branch-probability -fno-defer-pop -fno-crossjumping -fno-thread-jumps " which command line setting should be equal to -O0, but I still didn't get the consistent result. 
> I wonder whether there is any additional optimization enabled by -O1 for C++ language which is not documented in GCC manual?

See http://gcc.gnu.org/bugs.html for info on how to submit a proper bug
report.

You didn't mention the target, but this is almost certainly an x86.
This is a common problem for x86 users.  This is partly a design flaw
with the x87 FP register stack, and partly an implementation flaw with
the gcc x86 back end.  Unfortunately, there is no good solution that
makes everyone happy, since the only way to get accurate FP results on
the x87 is to sacrifice performance.  GCC should at least provide this
as an option, but unfortunately does not yet, even though the problem
has been known for well over a decade.

The only really good solution is to stop using the x87 FP register
stack.  This is done by default in x86_64-linux.  For x86, there are
some options that might help, such as -mfpmath=sse.  This will only work
with recent gcc versions and recent x86 processors, and may take some
experimentation.  Sometimes -ffloat-store helps.

There is a lot of info about this problem in PR 323.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com