From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24654 invoked by alias); 10 Feb 2014 09:21:04 -0000 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 Received: (qmail 24595 invoked by uid 48); 10 Feb 2014 09:20:58 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode Date: Mon, 10 Feb 2014 09:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00931.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60116 --- Comment #11 from Uro=C5=A1 Bizjak --- OK, confirmed using "-Os -m32" with gcc version 4.9.0 20140207 (experimental) [trunk revision 207597] (GCC)=20 on CentOS 5.10. It looks like a fault in the combine pass. Before combine, we have: ... (insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ]) (mem/c:SI (symbol_ref:SI ("d") [flags 0x2] ) [2 d+0 S4 A32])) t.c:18 90 {*movsi_internal} (nil)) ... (insn 33 32 34 5 (set (reg:SI 113 [ D.1782 ]) (sign_extend:SI (reg:QI 91 [ D.1785 ]))) t.c:17 148 {extendqisi2} (nil)) (insn 34 33 35 5 (set (reg:SI 114 [ D.1782 ]) (not:SI (reg:SI 113 [ D.1782 ]))) t.c:17 510 {*one_cmplsi2_1} (expr_list:REG_DEAD (reg:SI 113 [ D.1782 ]) (nil))) (insn 35 34 37 5 (parallel [ (set (reg:DI 115 [ D.1786 ]) (sign_extend:DI (reg:SI 114 [ D.1782 ]))) (clobber (reg:CC 17 flags)) (clobber (scratch:SI)) ]) t.c:17 143 {extendsidi2_1} (expr_list:REG_DEAD (reg:SI 114 [ D.1782 ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) (insn 37 35 38 5 (parallel [ (set (reg:SI 117) (ior:SI (subreg:SI (reg:DI 115 [ D.1786 ]) 0) (subreg:SI (reg:DI 115 [ D.1786 ]) 4))) (clobber (reg:CC 17 flags)) ]) t.c:17 420 {*iorsi_1} (expr_list:REG_DEAD (reg:DI 115 [ D.1786 ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) (insn 38 37 39 5 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 117) (const_int 0 [0]))) t.c:17 3 {*cmpsi_ccno_1} (expr_list:REG_DEAD (reg:SI 117) (nil))) (insn 39 38 41 5 (set (reg:QI 119) (ne:QI (reg:CCZ 17 flags) (const_int 0 [0]))) t.c:17 624 {*setcc_qi} (expr_list:REG_DEAD (reg:CCZ 17 flags) (nil))) (insn 41 39 83 5 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 101 [ D.1782 ]) (const_int 0 [0]))) t.c:18 3 {*cmpsi_ccno_1} (nil)) (insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ]) (zero_extend:SI (reg:QI 119))) 138 {*zero_extendqisi2} (expr_list:REG_DEAD (reg:QI 119) (nil))) (jump_insn 42 83 43 5 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref 47) (pc))) t.c:18 628 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags) (int_list:REG_BR_PROB 5000 (nil))) -> 47) Please note (insn 41) that sets flags for (jump_insn 42), comparing (reg:SI 101) a.k.a "d" with zero. Later, combine mass-deletes everything from (insn 33) to (insn 83) to substitute (insn 83) with constant load: ... (insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ]) (mem/c:SI (symbol_ref:SI ("d") [flags 0x2] ) [2 d+0 S4 A32])) t.c:18 90 {*movsi_internal} (nil)) ... (note 33 32 34 5 NOTE_INSN_DELETED) (note 34 33 35 5 NOTE_INSN_DELETED) (note 35 34 37 5 NOTE_INSN_DELETED) (note 37 35 39 5 NOTE_INSN_DELETED) (note 39 37 41 5 NOTE_INSN_DELETED) (note 41 39 83 5 NOTE_INSN_DELETED) (insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ]) (const_int 1 [0x1])) 90 {*movsi_internal} (nil)) (jump_insn 42 83 43 5 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0])) (label_ref 47) (pc))) t.c:18 628 {*jcc_1} (expr_list:REG_DEAD (reg:CCZ 17 flags) (int_list:REG_BR_PROB 5000 (nil))) -> 47) Unfortunately unrelated (insn 41) is also killed, so flags are taken from unrelated operation (that happens to be insn 32, just above insn 33). Things go downhill from there. >>From gcc-bugs-return-443175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 10 09:21:32 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 25386 invoked by alias); 10 Feb 2014 09:21:32 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 25326 invoked by uid 48); 10 Feb 2014 09:21:29 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode Date: Mon, 10 Feb 2014 09:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00932.txt.bz2 Content-length: 417 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60116 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- Component|target |rtl-optimization --- Comment #12 from Uro=C5=A1 Bizjak --- Re-confirmed as rtl-optimization problem. >>From gcc-bugs-return-443176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 10 09:29:17 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28973 invoked by alias); 10 Feb 2014 09:29:17 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 28941 invoked by uid 48); 10 Feb 2014 09:29:12 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL) Date: Mon, 10 Feb 2014 09:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: build, ice-on-valid-code X-Bugzilla-Severity: critical X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00933.txt.bz2 Content-length: 2278 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #25 from Richard Biener --- (In reply to Jeffrey A. Law from comment #24) > This is a mess. > > As noted in the other comments, we're considering a cc0-setter as a > potentially trapping insn. As a result the cc0-setter and cc0-consumer end > up in different blocks. > > That's bad on so many levels and "fixing" it by hacking up fold_rtx like > this just papers over the fundamental problem (though I must admit from a > pragmatic standpoint, it's pretty effective). > > One could argue that the CFG building code could be tweaked so that a > cc0-setter is never considered the end of a block. The downside of that is > we're lying to the compiler about the true nature of the CFG. But that > little white lie may be acceptable. I haven't looked into how ugly that > would be to implement. Well, it re-exposes the original problem of not properly handling EH with -fnon-call-exception and trapping FP comparisons? I don't recall all the issues with the original case I installed the change (at least we do consider GIMPLE_CONDs as possibly trapping, just we don't allow a possibly throwing condition in a GIMPLE_COND). One fix for backends where cc0 setter and consumer may not be separated is to duplicate the comparison like ... g >= 0.0; // stmt ending BB with EH edges if (g >= 0.0) // redundant compare, but with NOTHROW set ... Or to revert the original change and think of a better fix. But certainly you can't rely on the IL being if (g >= 0.0) instead of (what gimplification forces now) bool tem = g >= 0.0; if (tem != 0) because with -fnon-call-exceptions writing that literally in C++ and compiling with -O0 will yield exactly the same issue as you hit it now (separated cc0 setter / consumer). So reverting wouldn't be a "real" fix. Testcase: int foo (double x) { try { bool cond = x >= 0.0; if (cond) return 1; return 0; } catch (...) { return -1; } } Where we shouldn't ICE when reverting the original fix and which at -O0 produces exactly the same "issue" you face now. Best it into a runtime testcase that properly catches a trapping compare. Richard.