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

[Richard Earnshaw]

> 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.