public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/9052: in C code, "if" statement fails to execute if optimized Date: Wed, 12 Feb 2003 16:26:00 -0000 [thread overview] Message-ID: <20030212162600.29552.qmail@sources.redhat.com> (raw) 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.
next reply other threads:[~2003-02-12 16:26 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-02-12 16:26 Richard Earnshaw [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-02-18 10:41 ebotcazou 2003-02-14 21:16 Toon Moene 2003-02-13 21:56 Eric Botcazou 2003-02-13 19:46 Toon Moene 2003-02-13 11:56 Eric Botcazou 2003-02-12 17:06 Steven Bosscher 2003-02-12 16:56 Eric Botcazou 2003-02-12 16:46 Richard Earnshaw 2003-02-12 16:36 Steven Bosscher 2003-02-12 15:26 Steven Bosscher 2002-12-24 5:36 phma
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030212162600.29552.qmail@sources.redhat.com \ --to=rearnsha@arm.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).