From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20009 invoked by alias); 8 Jan 2010 05:27:23 -0000 Received: (qmail 19960 invoked by uid 48); 8 Jan 2010 05:27:10 -0000 Date: Fri, 08 Jan 2010 05:27:00 -0000 Message-ID: <20100108052710.19959.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "aoliva at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00894.txt.bz2 ------- 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