This is the mail archive of the
gcc-bugs@gcc.gnu.org
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: Richard dot Earnshaw at arm dot com
- Cc: gcc-gnats at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org,gcc-prs at gcc dot gnu dot org, phama at webjockey dot net,Eric Botcazou <ebotcazou at libertysurf dot fr>
- Date: 12 Feb 2003 17:30:01 +0100
- Subject: Re: optimization/9052: in C code, "if" statement fails to executeif optimized
- References: <200302121624.h1CGO9G31917@pc960.cambridge.arm.com>
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