Message ID | 63e16891-28c6-aa37-6f1a-1288a19e9cfe@oracle.com |
---|---|
State | New |
Headers | show |
Series | [C++,Patch/RFC] PR 82593 ("Internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1294") | expand |
Hi, any feedback about this - apparently rather simple - issue? On 03/11/2017 18:33, Paolo Carlini wrote: > Hi, > > this ICE on valid (given GNU's designated initializers) is rather > simple to analyze: for the testcase, the gcc_assert in > process_init_constructor_array triggers because at that time INDEX1 is > still a CONST_DECL, not an INTEGER_CST. As regards fixing the problem, > I immediately noticed earlier today that fold_non_dependent_expr is > definitely able to fold the CONST_DECL to the expected zero > INTEGER_CST - and that also passes testing - but I'm not sure that in > the big picture folding at that time is correct. Thanks in advance for > any feedback! https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00242.html Thanks! Paolo
Index: cp/typeck2.c =================================================================== --- cp/typeck2.c (revision 254365) +++ cp/typeck2.c (working copy) @@ -1291,6 +1291,7 @@ process_init_constructor_array (tree type, tree in { if (ce->index) { + ce->index = fold_non_dependent_expr (ce->index); gcc_assert (TREE_CODE (ce->index) == INTEGER_CST); if (compare_tree_int (ce->index, i) != 0) { Index: testsuite/g++.dg/cpp0x/desig2.C =================================================================== --- testsuite/g++.dg/cpp0x/desig2.C (nonexistent) +++ testsuite/g++.dg/cpp0x/desig2.C (working copy) @@ -0,0 +1,23 @@ +// PR c++/82593 +// { dg-do compile { target c++11 } } +// { dg-options "" } + +enum { + INDEX1 = 0, + INDEX2 +}; + +class SomeClass { +public: + SomeClass(); +private: + struct { int field; } member[2]; +}; + +SomeClass::SomeClass() + : member({ + [INDEX1] = { .field = 0 }, + [INDEX2] = { .field = 1 } + }) +{ +}