Created attachment 31897 [details] Reduced preprocessed code. g++ --version g++ (GCC) 4.9.0 20140120 (experimental) as of rev 206794 When compiling the attached preprocessed code (somewhat reduced), I get the following ICE: g++ -std=gnu++11 DnsLocatorProfiles.ii functional/protocols/dnslocator/DnsLocatorProfiles.cpp: In function ‘void __static_initialization_and_destruction_0(int, int)’: functional/protocols/dnslocator/DnsLocatorProfiles.cpp:58:5: internal compiler error: in expand_expr_real_2, at expr.c:9201 }; ^ 0x77c193 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:9201 0x6c122c expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3249 0x6c122c expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3309 0x6c18cb expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5149 0x6c3dc6 gimple_expand_cfg ../../gcc/gcc/cfgexpand.c:5715 0x6c3dc6 execute ../../gcc/gcc/cfgexpand.c:5935
Add likely suspects to Cc.
You must be building with release checking, right, otherwise I don't see how this could have made all the way till expansion. Anyway, the suspect commit is actually r206639, we have a GIMPLE_ASSIGN with RANGE_EXPR on the rhs, which is of course invalid.
Yes, the compiler is built with: ../gcc/configure --prefix=/opt/gcc/gcc-trunk --enable-checking=release --enable-languages=c,c++,lto
Thus confirmed.
Reduced testcase: struct A { A (); ~A (); }; struct B { A b[4]; }; struct C { B c[5]; }; const C e = {};
Even the const there isn't needed. Anyway, the bug I think is that split_nonconstant_init_1 doesn't handle RANGE_EXPR field_index in the if (TREE_CODE (value) == CONSTRUCTOR) case (it handles it in the else if (!initializer_constant_valid_p (value, inner_type)) case).
Created attachment 31900 [details] gcc49-pr59886.patch Untested partial patch. I believe we want to increment the num_split_elts for all the elements in the range, not just the first one. And I think we need a loop around the inner split_nonconstant_init_1 emitted code, e.g. as done in the attached patch (completely untested). What the patch doesn't handle and probably has to is a cleanup for it though, which if the construction throws in the second or later iteration will just destruct everything the earlier iterations constructed, right? I think the current iteration will be already properly destructed (or not constructed at all). Jason, can you please have a look and take this over?
Author: jason Date: Fri Jan 24 16:47:54 2014 New Revision: 207051 URL: http://gcc.gnu.org/viewcvs?rev=207051&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * typeck2.c (process_init_constructor_array): Don't create RANGE_EXPR yet. Added: trunk/gcc/testsuite/g++.dg/init/aggr10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
Fixed by reverting the RANGE_EXPR change.
Author: jason Date: Fri Jan 24 17:09:07 2014 New Revision: 207052 URL: http://gcc.gnu.org/viewcvs?rev=207052&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * g++.dg/opt/value-init2.C: Remove. Removed: trunk/gcc/testsuite/g++.dg/opt/value-init2.C