From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16366 invoked by alias); 25 Mar 2012 13:48:04 -0000 Received: (qmail 16350 invoked by uid 22791); 25 Mar 2012 13:48:02 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Sun, 25 Mar 2012 13:47:50 +0000 From: "aoliva at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/52306] ICE in CSE Date: Sun, 25 Mar 2012 13:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aoliva at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Ever Confirmed Message-ID: In-Reply-To: References: 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-03/txt/msg02172.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Alexandre Oliva changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2012-03-25 CC| |bernds at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Alexandre Oliva 2012-03-25 13:46:43 UTC --- FWIW, the problem is AFAICT still present in mainline, but it is latent, for the testcase no longer triggers the problem that 4.6 did. The only change I could find to relevant portions of the reload code was the fix for bug 47976, but it doesn't seem to fix this particular issue. Regardless, maybe Bernd can offer some guidance since he's the reload expert ;-) In GCC 4.6 r185770, the reloads for insn 288 are: Reloads for insn # 288 Reload 0: reload_in (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) reload_out (SI) = (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) ADDR_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), inc by 4 reload_in_reg: (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) reload_reg_rtx: (reg:SI 9 %a1) Reload 1: reload_out (SI) = (reg/f:SI 124 [ D.1788 ]) GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional reload_out_reg: (reg/f:SI 124 [ D.1788 ]) Reload 2: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base: D.1889_285, offset: 0B]+0 S4 A16]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base: D.1889_285, offset: 0B]+0 S4 A16]) in GCC trunk r185451, the same insn is numbered 296, and it has a single reload, for both pseudos already got REGs: Reload 0: reload_in (SI) = (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110 ivtmp.82 ] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16]) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional reload_in_reg: (mem/f:SI (post_inc:SI (reg:SI 9 %a1 [orig:110 ivtmp.82 ] [110])) [4 MEM[base: D.1990_299, offset: 0B]+0 S4 A16])