[Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084

["trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 7458 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405

Markus Trippelsdorf <trippels at gcc dot gnu.org> 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 <trippels at gcc dot gnu.org> ---
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 <typename... Args>
  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=c++11 -c sex.ii
sex.ii: In instantiation of ‘ListSyntax* A::m_fn1(Args& ...) [with Args =
{const int, bool}]’:
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*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
        ../../gcc/gcc/cp/call.c:8168
0x584569 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, 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*, va_gc, vl_embed>**, tree_node*, tree_node*,
vec<tree_node*, va_gc, vl_embed>**, int, int)
        ../../gcc/gcc/cp/init.c:3086
0x5fc209 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
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: <gcc-bugs-return-462843-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-61605-4-L0Ao1cuyez@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61605-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61605-4@http.gcc.gnu.org/bugzilla/>
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?ida605

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3610&actioníit
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.