public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aoliva at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"
Date: Fri, 08 Jan 2010 05:27:00 -0000 [thread overview]
Message-ID: <20100108052710.19959.qmail@sourceware.org> (raw)
In-Reply-To: <bug-42631-14164@http.gcc.gnu.org/bugzilla/>
------- Comment #12 from aoliva at gcc dot gnu dot org 2010-01-08 05:27 -------
It is a bug. The compiler shouldn't generate different code depending on -g,
and that's what's (potentially) going on here. That the code is undefined per
a language standard shouldn't take precedence over a more general design
principle in GCC: we should still emit the same code, crash or exhibit
otherwise undefined behavior in just the same way. Surely you wouldn't like to
have a surprise such as finding out the crash or the bug you're hunting
disappears when you recompile the program with -g, would you? That's the kind
of bug that -fcompare-debug is designed to catch, and that's what it just did.
Now, since leaving the bug in *would* do harm (as above), the question is
whether to fix it in DF or in web. I'm ambivalent, but I'd rather not put time
into either one if it's going to be rejected in favor of the other.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631
next prev parent reply other threads:[~2010-01-08 5:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-06 0:50 [Bug debug/42631] New: " zsojka at seznam dot cz
2010-01-06 12:00 ` [Bug rtl-optimization/42631] [4.5 Regression] " rguenth at gcc dot gnu dot org
2010-01-06 12:33 ` steven at gcc dot gnu dot org
2010-01-06 23:48 ` steven at gcc dot gnu dot org
2010-01-06 23:54 ` steven at gcc dot gnu dot org
2010-01-07 13:54 ` aoliva at gcc dot gnu dot org
2010-01-07 14:54 ` rguenth at gcc dot gnu dot org
2010-01-07 19:55 ` steven at gcc dot gnu dot org
2010-01-07 20:44 ` aoliva at gcc dot gnu dot org
2010-01-08 1:01 ` aoliva at gcc dot gnu dot org
2010-01-08 1:27 ` aoliva at gcc dot gnu dot org
2010-01-08 1:56 ` zadeck at naturalbridge dot com
2010-01-08 2:44 ` aoliva at gcc dot gnu dot org
2010-01-08 3:52 ` zadeck at naturalbridge dot com
2010-01-08 5:27 ` aoliva at gcc dot gnu dot org [this message]
2010-01-09 14:42 ` aoliva at gcc dot gnu dot org
2010-01-09 14:50 ` aoliva at gcc dot gnu dot org
[not found] <bug-42631-4@http.gcc.gnu.org/bugzilla/>
2011-02-05 12:06 ` jiez at gcc dot gnu.org
2011-02-10 4:23 ` jiez at gcc dot gnu.org
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=20100108052710.19959.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@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: link
Be 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).