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

[Steven Bosscher]

Op wo 12-02-2003, om 17:24 schreef 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".

Pfewww, good.

Still it is a change in behavior of the generated code.  Should it be
documented?
Greetz
Steven