This is the mail archive of the
mailing list for the GCC project.
Re: optimization/9052: in C code, "if" statement fails to executeif optimized
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 12 Feb 2003 16:36:01 -0000
- Subject: Re: optimization/9052: in C code, "if" statement fails to executeif optimized
- Reply-to: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
The following reply was made to PR optimization/9052; it has been noted by GNATS.
From: Steven Bosscher <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
Eric Botcazou <firstname.lastname@example.org>
Subject: Re: optimization/9052: in C code, "if" statement fails to execute
Date: 12 Feb 2003 17:30:01 +0100
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".
Still it is a change in behavior of the generated code. Should it be