From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124010 invoked by alias); 24 Feb 2015 21:31:33 -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 123974 invoked by uid 48); 24 Feb 2015 21:31:29 -0000 From: "maltsevm at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/65154] ICE with {} initialized array with string Date: Tue, 24 Feb 2015 22:30: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: maltsevm at gmail dot com 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: cc 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: 2015-02/txt/msg02712.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 Mikhail Maltsev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- 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]; <>>; 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 ; <>> >>>>}) >>>>>; <<< Unknown tree: expr_stmt (void) ++D.2138 >>>; (void) --D.2139; } :; Here is a backtrace which leads to construction of such expression: #0 convert_like_real (convs=0x23f8820, expr=, fn=, 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=, expr=, complain=3, flags=5) at /home/miyuki/gcc/src/gcc/cp/call.c:9418 #2 0x0000000000856da8 in convert_for_initialization (exp=, type=, rhs=, flags=5, errtype=ICR_INIT, fndecl=, 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=, type=, rhs=, flags=5, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348 #6 0x000000000078a301 in digest_init_r (type=, init=, nested=true, flags=5, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1126 #7 0x000000000078a5ef in massage_init_elt (type=, init=, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1190 #8 0x000000000078b4dd in process_init_constructor_record (type=, init=, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1395 #9 0x000000000078beb1 in process_init_constructor (type=, init=, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1562 #10 0x000000000078a159 in digest_init_r (type=, init=, nested=false, flags=5, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1094 #11 0x000000000078a336 in digest_init (type=, init=, complain=3) at /home/miyuki/gcc/src/gcc/cp/typeck2.c:1133 #12 0x000000000086d81d in expand_default_init (binfo=, true_exp=, exp=, init=, flags=1, complain=3) #13 0x000000000086e4f3 in expand_aggr_init_1 (binfo=, true_exp=, exp=, init=, flags=1, complain=3) at /home/miyuki/gcc/src/gcc/cp/init.c:1830 #14 0x000000000086d431 in build_aggr_init (exp=, init=, flags=0, complain=3) at /home/miyuki/gcc/src/gcc/cp/init.c:1582 #15 0x000000000087493d in build_vec_init (base=, maxindex=, init=, 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=, init=, flags=2049, complain=3) at /home/miyuki/gcc/src/gcc/cp/init.c:1563 #17 0x00000000006e192d in build_aggr_init_full_exprs (decl=, init=, 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 ) 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).