From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32643 invoked by alias); 29 Sep 2014 11:31:10 -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 32615 invoked by uid 48); 29 Sep 2014 11:31:06 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084 Date: Mon, 29 Sep 2014 11:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trippels 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: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc cf_known_to_work version target_milestone short_desc everconfirmed cf_known_to_fail 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-09/txt/msg02676.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63405 Markus Trippelsdorf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2014-09-29 CC| |trippels at gcc dot gnu.org Known to work| |4.8.3, 4.9.2 Version|4.9.1 |5.0 Target Milestone|--- |5.0 Summary|Internal compiler error |[5 regression] ICE in |when building OpenAxiom on |cp_perform_integral_promoti |linux/amd64 |ons, at cp/typeck.c:2084 Ever confirmed|0 |1 Known to fail| |5.0 --- Comment #1 from Markus Trippelsdorf --- I can only reproduce this on trunk. 4.9 branch is fine. markus@x4 tmp % cat sex.ii struct ListSyntax { ListSyntax(int, bool); }; struct A { template ListSyntax *m_fn1(Args &... args) { return new ListSyntax{args...}; } }; struct B { const ListSyntax *m_fn2(const int &, bool); A lists; }; const ListSyntax *B::m_fn2(const int &elts, bool dot) { return lists.m_fn1(elts, dot); } markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -std=3Dc++11 -c sex.ii sex.ii: In instantiation of =E2=80=98ListSyntax* A::m_fn1(Args& ...) [with = Args =3D {const int, bool}]=E2=80=99: sex.ii:15:31: required from here sex.ii:7:34: internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2084 return new ListSyntax{args...}; ^ 0x6b79d1 cp_perform_integral_promotions(tree_node*, int) ../../gcc/gcc/cp/typeck.c:2084 0x57335a convert_for_arg_passing(tree_node*, tree_node*, int) ../../gcc/gcc/cp/call.c:6799 0x577b83 build_over_call ../../gcc/gcc/cp/call.c:7211 0x5835f5 build_new_method_call_1 ../../gcc/gcc/cp/call.c:8098 0x5835f5 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:8168 0x584569 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int) ../../gcc/gcc/cp/call.c:7712 0x6e564b build_new_1 ../../gcc/gcc/cp/init.c:2846 0x6e5d16 build_new(vec**, tree_node*, tree_nod= e*, vec**, int, int) ../../gcc/gcc/cp/init.c:3086 0x5fc209 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, boo= l, bool) ../../gcc/gcc/cp/pt.c:14848 0x5db056 tsubst_expr ../../gcc/gcc/cp/pt.c:14272 0x5dc89c tsubst_expr ../../gcc/gcc/cp/pt.c:13679 0x5dbe60 tsubst_expr ../../gcc/gcc/cp/pt.c:13855 0x5d90fd instantiate_decl(tree_node*, int, bool) ../../gcc/gcc/cp/pt.c:20227 0x61f727 instantiate_pending_templates(int) ../../gcc/gcc/cp/pt.c:20343 0x65c9e4 cp_write_global_declarations() ../../gcc/gcc/cp/decl2.c:4367 Please submit a full bug report, >>From gcc-bugs-return-462843-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 12:10:29 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 11601 invoked by alias); 29 Sep 2014 12:10:29 -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 11564 invoked by uid 48); 29 Sep 2014 12:10:25 -0000 From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls Date: Mon, 29 Sep 2014 12:10: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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries 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-Flags: X-Bugzilla-Changed-Fields: attachments.created 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-09/txt/msg02677.txt.bz2 Content-length: 2251 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 --- Comment #5 from vries at gcc dot gnu.org --- Created attachment 33610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33610&action=edit proof-of-concept patch Using this proof-of-concept patch, we manage to get the desired code. The patch uses the fuse-caller-save information in cprop-hardreg, and runs cprop-hardreg one more time, after pass_fast_rtl_dce. Obviously it's not desirable to run cprop-hardreg twice. But the pass has problems with this code: ... (insn 2 18 3 2 (set (reg/v:SI 1 dx [orig:86 yD.1749 ] [86]) (reg:SI 5 di [ yD.1749 ])) test.c:9 90 {*movsi_internal} (expr_list:REG_DEAD (reg:SI 5 di [ yD.1749 ]) (nil))) (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG) (insn 6 3 7 2 (set (reg:SI 5 di) (reg/v:SI 1 dx [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal} (nil)) ... The first time cprop-hardreg runs, it manages to propagate the first copy (insn 2) to the second (insn 6): ... rescanning insn with uid = 6. insn 6: replaced reg 1 with 5 ... So insn 6 looks like: ... (insn 6 3 7 2 (set (reg:SI 5 di) (reg:SI 5 di [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal} (nil)) ... That insn is remove by pass_fast_rtl_dce: ... DCE: Deleting insn 6 deleting insn with uid = 6. ... And only the second time we run it, we propagate the first copy to the add: ... insn 9: replaced reg 1 with 5 rescanning insn with uid = 9. ... which then looks like this: ... (insn 9 7 15 2 (parallel [ (set (reg:SI 0 ax [orig:87 D.1767 ] [87]) (plus:SI (reg:SI 0 ax [orig:83 D.1767 ] [83]) (reg:SI 5 di [orig:86 yD.1749 ] [86]))) (clobber (reg:CC 17 flags)) ]) test.c:10 220 {*addsi_1} (expr_list:REG_DEAD (reg/v:SI 1 dx [orig:86 yD.1749 ] [86]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) ... That leaves insn 2 dead, which is deleted by dce during sched2: ... DCE: Deleting insn 2 deleting insn with uid = 2. ... I'm not sure yet why the cprop-hardreg doesn't work for both cases the first time, but it's probably that the store to di by insn 6 is registered as a kill by cprop-hardreg, not taking into account that it's the same value.