Re: optimization/9052: in C code, "if" statement fails to execute if optimized

[Richard Earnshaw <rearnsha at arm dot com>]

The following reply was made to PR optimization/9052; it has been noted by GNATS.

From: Richard Earnshaw <rearnsha@arm.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
        gcc-prs@gcc.gnu.org, phama@webjockey.net,
        Eric Botcazou <ebotcazou@libertysurf.fr>, Richard.Earnshaw@arm.com
Subject: Re: optimization/9052: in C code, "if" statement fails to execute 
 if optimized
Date: Wed, 12 Feb 2003 16:24:09 +0000

 > Reading specs from
 > /opt/experimental/lib/gcc-lib/i586-pc-linux-gnu/3.4/specs
 > Configured with: ../gcc-trunk/configure --disable-nls --with-gnu-as
 > --with-gnu-ld --prefix=/opt/experimental --program-suffix=-3.4
 > --enable-languages=c
 > Thread model: posix
 > gcc version 3.4 20030211 (experimental)
 > 
 > Output from this testcase:
 > gcc version:	at -O0		at -O1		at -O2
 > 2.95.3		 22		 22		 22
 > 3.4 exp.	 22		256		256
 > 
 > After uncommenting the printf, gcc 3.4 also prints 22 at -O1 and -O2.
 > 
 > I have looked for documentation about this change in behavior but it
 > doesn't seem to exist. I'm not a floating point specialist, but
 > generally, comparing floats for equality doesn't seem like the best
 > thing to do.  However, since it apparently worked with older gcc
 > versions, I suppose one could qualify this as a regression...
 > 
 > Eric, I CC'ed you as the Great C Bug Squasher.  Do you think this is a
 > regression, and if so, change the status in GNATS?
 
 Adding -ffloat-store will probably also make the "misbehaviour" go away.
 
 GCC is almost certainly using the register result from the current 
 iteration to compare with the memory result from an earlier iteration.  
 Since the register result has excess precision the compare for equality 
 fails.  That's not a bug, it's just the FP works on the X86.
 
 So in summary, almost certainly "not a bug".
 
 R.