From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26938 invoked by alias); 27 Feb 2012 09:32:45 -0000 Received: (qmail 26927 invoked by uid 22791); 27 Feb 2012 09:32:44 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_FW X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Feb 2012 09:32:31 +0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/52397] New: [4.7 regression] comparison failure with Ada enabled Date: Mon, 27 Feb 2012 09:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-02/txt/msg02536.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 Bug #: 52397 Summary: [4.7 regression] comparison failure with Ada enabled Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned@gcc.gnu.org ReportedBy: ebotcazou@gcc.gnu.org Host: ia64-*-linux Target: ia64-*-linux Build: ia64-*-linux We have a bootstrap comparison failure on IA-64 with Ada enabled: Bootstrap comparison failure! gcc/ada/uintp.o differs make[2]: *** [compare] Error 1 This is a debug insn issue. The -fdump-final-insns diff reads: --- uintp.s.gkd.0 2012-02-25 11:33:14.050677000 -0500 +++ uintp.s.gkd.1 2012-02-25 11:33:58.240145000 -0500 @@ -3350,7 +3350,7 @@ (unspec_volatile:DI [ (const_int 0 [0]) ] UNSPECV_ALLOC)) - (use (const_int 6 [0x6])) + (use (const_int 5 [0x5])) (use (const_int 8 [0x8])) (use (const_int 2 [0x2])) (use (const_int 0 [0])) This happens because r117 (in5) is df_regs_ever_live_p by the time the prologue is expanded with debug insns but isn't without debug insns. It is referenced in a debug insns after fwprop1: (debug_insn 111 109 5 2 (var_location:DI D#136 (reg:DI 117 in5 [ quotient+8 ])) -1 (nil)) and eliminated after dse1: (debug_insn 111 109 5 2 (var_location:DI D#136 (clobber (const_int 0 [0]))) -1 (nil)) The debug_insn is generated by delete_trivially_dead_insns but isn't reset in the second phase of the same processing because the register isn't a pseudo. Now reginfo is run between fwprop1 and dse1 so the df_hard_reg_used_p r117 is consequently computed as being regs_ever_live by df_compute_regs_ever_live called from reginfo_init and nothing resets this afterwards (df_analyze does call df_compute_regs_ever_live too but with RESET to false). Teaching df_compute_regs_ever_live to reset individual registers leads to DF verification failures for artificial registers.