[Bug c++/65154] New: ICE with {} initialized array with string

[Bug c++/65154] New: ICE with {} initialized array with string

[pinskia at gcc dot gnu.org]

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

            Bug ID: 65154
           Summary: ICE with {} initialized array with string
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org

Non-reduced unincluded testcase:
#include <string>

struct C {
  std::string s;
};

int main() {
  C cs[5]{};
}

--- CUT ---
t.cc: In function ‘int main()’:
t.cc:8:11: internal compiler error: in gimplify_init_constructor, at
gimplify.c:4109
   C cs[5]{};
           ^
Please submit a full bug report,
with preprocessed source if appropriate.
>From gcc-bugs-return-478038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Feb 21 10:21:08 2015
Return-Path: <gcc-bugs-return-478038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22886 invoked by alias); 21 Feb 2015 10:21:08 -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 22850 invoked by uid 48); 21 Feb 2015 10:21:05 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65154] ICE with {} initialized array with string
Date: Sat, 21 Feb 2015 12:47: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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia 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-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65154-4-T49VPJWeIY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65154-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65154-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: 2015-02/txt/msg02370.txt.bz2
Content-length: 224

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide154

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
struct ss {
    ss() {};
};
struct C {
      ss s;
};
int main() {
      C cs[5]{};
}

[Bug c++/65154] ICE with {} initialized array with string

[maltsevm at gmail dot com]

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

Mikhail Maltsev <maltsevm at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maltsevm at gmail dot com

--- Comment #2 from Mikhail Maltsev <maltsevm at gmail dot com> ---
I did some analysis of this bug, and want to share my results, though I still
don't known, which part of the code should be fixed (and I'm asking for
advice).
ICE happens, when gimplifier tries to lower the constructor but gets some
language specific expression. The function body looks like this (for the second
test case, slightly modified: array contains one element):

  struct C cs[1];

    struct C cs[1];
  <<cleanup_point <<< Unknown tree: expr_stmt
  (void) (struct C[1] *)   struct C * D.2137;
  <<< Unknown tree: expr_stmt
  (void) (D.2137 = (struct C *) &cs) >>>;
    struct C * D.2138;
  <<< Unknown tree: expr_stmt
  (void) (D.2138 = D.2137) >>>;
    long int D.2139;
  <<< Unknown tree: expr_stmt
  (void) (D.2139 = 0) >>>;
  while (1)
    {
      if (D.2139 == -1) goto <D.2150>;
      <<cleanup_point <<< Unknown tree: expr_stmt
  (void) (*D.2138 = {TARGET_EXPR <D.2140, <<< Unknown tree: aggr_init_expr
  4
  __comp_ctor 
  D.2140
  (struct ss *) <<< Unknown tree: void_cst >>> >>>>}) >>>>>;
      <<< Unknown tree: expr_stmt
  (void)  ++D.2138 >>>;
      (void)  --D.2139;
    }
  <D.2150>:;

Here is a backtrace which leads to construction of such expression:

#0  convert_like_real (convs=0x23f8820, expr=<target_expr 0x7ffff618b118>,
fn=<tree 0x0>, argnum=0, inner=0, issue_conversion_warnings=true,
c_cast_p=false, complain=3) at /home/miyuki/gcc/src/gcc/cp/call.c:6440
#1  0x00000000006c2e41 in perform_implicit_conversion_flags (type=<record_type
0x7ffff62d7690 ss>, expr=<constructor 0x7ffff62ec0d8>, complain=3, flags=5) at
/home/miyuki/gcc/src/gcc/cp/call.c:9418
#2  0x0000000000856da8 in convert_for_initialization (exp=<tree 0x0>,
type=<record_type 0x7ffff62d7690 ss>, rhs=<constructor 0x7ffff62ec0d8>,
flags=5, errtype=ICR_INIT, fndecl=<tree 0x0>, parmnum=0, complain=3)
    at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348

(continued, same call to convert_for_initialization as in previous backtrace)

#5  0x0000000000856da8 in convert_for_initialization (exp=<tree 0x0>,
type=<record_type 0x7ffff62d7690 ss>, rhs=<constructor 0x7ffff62ec0d8>,
flags=5, errtype=ICR_INIT, fndecl=<tree 0x0>, parmnum=0, complain=3)
    at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348
#6  0x000000000078a301 in digest_init_r (type=<record_type 0x7ffff62d7690 ss>,
init=<constructor 0x7ffff62ec0d8>, nested=true, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1126
#7  0x000000000078a5ef in massage_init_elt (type=<record_type 0x7ffff62d7690
ss>, init=<constructor 0x7ffff62ec0d8>, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1190
#8  0x000000000078b4dd in process_init_constructor_record (type=<record_type
0x7ffff62d7d20 C>, init=<constructor 0x7ffff62dffc0>, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1395
#9  0x000000000078beb1 in process_init_constructor (type=<record_type
0x7ffff62d7d20 C>, init=<constructor 0x7ffff62dffc0>, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1562
#10 0x000000000078a159 in digest_init_r (type=<record_type 0x7ffff62d7d20 C>,
init=<constructor 0x7ffff62dffc0>, nested=false, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1094
#11 0x000000000078a336 in digest_init (type=<record_type 0x7ffff62d7d20 C>,
init=<constructor 0x7ffff62dffc0>, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1133
#12 0x000000000086d81d in expand_default_init (binfo=<tree_binfo
0x7ffff62da600>, true_exp=<indirect_ref 0x7ffff62ed0a0>, exp=<indirect_ref
0x7ffff62ed0a0>, init=<constructor 0x7ffff62dffc0>, flags=1, complain=3)
#13 0x000000000086e4f3 in expand_aggr_init_1 (binfo=<tree_binfo
0x7ffff62da600>, true_exp=<indirect_ref 0x7ffff62ed0a0>, exp=<indirect_ref
0x7ffff62ed0a0>, init=<constructor 0x7ffff62dffc0>, flags=1, complain=3)
    at /home/miyuki/gcc/src/gcc/cp/init.c:1830
#14 0x000000000086d431 in build_aggr_init (exp=<indirect_ref 0x7ffff62ed0a0>,
init=<constructor 0x7ffff62dffc0>, flags=0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1582
#15 0x000000000087493d in build_vec_init (base=<var_decl 0x7ffff62eb120>,
maxindex=<integer_cst 0x7ffff62dffd8>, init=<constructor 0x7ffff62dffc0>,
explicit_value_init_p=false, from_array=0, complain=3)
    at /home/miyuki/gcc/src/gcc/cp/init.c:3777
#16 0x000000000086d271 in build_aggr_init (exp=<var_decl 0x7ffff62eb000 cs>,
init=<constructor 0x7ffff62dffc0>, flags=2049, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1563
#17 0x00000000006e192d in build_aggr_init_full_exprs (decl=<var_decl
0x7ffff62eb000 cs>, init=<constructor 0x7ffff62dffc0>, flags=2049) at
/home/miyuki/gcc/src/gcc/cp/decl.c:5811

build_vec_init creates the loop, which performs elemtwise initialization of the
array. It is initialized with the same entity (direct initializer - here it is
seen as <constructor 0x7ffff62dffc0>) as the whole array. Then some strange
overload resolution is performed, which eventually gets resolved to the
user-defined default constructor (If I understood that right) and conversion is
applied to initializer before the call (which does not make sence).

Obviously the initializer must become "void" somewhere, but I don't known
what's the appropriate place for it. For example, some similar code (for
handling zero-initialization) is present in build_aggr_init, but this case
can't be handled there (because overload resolution must be performed, for a
case when class s has a constructor which accepts std::initializer_list).

[Bug c++/65154] ICE with {} initialized array with string

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-26
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.5
            Summary|ICE with {} initialized     |[4.8/4.9/5 Regression] ICE
                   |array with string           |with {} initialized array
                   |                            |with string

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
4.6 didn't ICE, thus a regression.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Most likely started with r175674.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[maltsevm at gmail dot com]

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

--- Comment #5 from Mikhail Maltsev <maltsevm at gmail dot com> ---
I have posted a patch for this bug:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00026.html
But it reveals some latent bug (PR65503). In the following case (after applying
the patch):

struct ss {
    ss() {};
};
struct C {
      ss s[1000];
};
int main() {
      C cs[5]{};
}

We'll get 1000 calls to ss() in main instead of calling default c-tor of struct
C. (which is probably not what we want).

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Mikhail Maltsev from comment #5)
> We'll get 1000 calls to ss() in main instead of calling default c-tor of
> struct C. (which is probably not what we want).

Agreed, we ought to use the default constructor for {}-initialization when we
can.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Thu Mar 26 19:51:58 2015
New Revision: 221704

URL: https://gcc.gnu.org/viewcvs?rev=221704&root=gcc&view=rev
Log:
    PR c++/65154
    * init.c (build_vec_init): Fix initializing aggregates
    with empty init list.

Added:
    trunk/gcc/testsuite/g++.dg/init/array39.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/init.c

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Thu Mar 26 19:52:00 2015
New Revision: 221705

URL: https://gcc.gnu.org/viewcvs?rev=221705&root=gcc&view=rev
Log:
    PR c++/65154
    * init.c (build_vec_init): Fix initializing aggregates
    with empty init list.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/init/array39.C
Modified:
    branches/gcc-4_9-branch/gcc/cp/ChangeLog
    branches/gcc-4_9-branch/gcc/cp/init.c

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.8.5                       |4.9.3

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for 4.9.3/5.