This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi,I have been spending some time on this regression, where we ICE in potential_constant_expression_1 because CLEANUP_STMT is unhandled. Apparently the ICE started with https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=238559, where we started calling maybe_constant_value from cp_fully_fold, but now happens in the same way with that commit reverted too. The context of the ICE is the following: from store_init_value we call maybe_constant_init for a __for_range VAR_DECL as decl and a COMPUND_EXPR as value:
<compound_expr 0x7ffff69bede8 type <reference_type 0x7ffff69de690 type <array_type 0x7ffff69d9f18 type <record_type 0x7ffff69d93f0 A> needs-constructing type_4 BLK size <integer_cst 0x7ffff68780d8 constant 32> unit size <integer_cst 0x7ffff68780f0 constant 4>align 32 symtab 0 alias set -1 canonical type 0x7ffff69d9f18 domain <integer_type 0x7ffff687fe70> pointer_to_this <pointer_type 0x7ffff69de1f8> reference_to_this <reference_type 0x7ffff69de5e8>>
private unsigned DI size <integer_cst 0x7ffff6856e88 constant 64> unit size <integer_cst 0x7ffff6856ea0 constant 8> align 64 symtab 0 alias set -1 canonical type 0x7ffff69de690> side-effects arg 0 <statement_list 0x7ffff69d5e20 type <void_type 0x7ffff687d000 void type_6 VOID align 8 symtab 0 alias set -1 canonical type 0x7ffff687d000 pointer_to_this <pointer_type 0x7ffff687d150>>side-effects head 0x7ffff69d3e28 tail 0x7ffff69d3e40 stmts 0x7ffff69d5e60 0x7ffff6855bd0
stmt <cleanup_point_expr 0x7ffff69d5e60 type <void_type 0x7ffff687d000 void>
side-effects tree_1arg 0 <expr_stmt 0x7ffff69d5e40 type <void_type 0x7ffff687d000 void>
side-effectsarg 0 <init_expr 0x7ffff69bec30 type <record_type 0x7ffff69d93f0 A>
side-effectsarg 0 <array_ref 0x7ffff6863188 type <record_type 0x7ffff69d93f0 A>
arg 0 <var_decl 0x7ffff69df090 D.2323>arg 1 <integer_cst 0x7ffff6856eb8 constant 0>> arg 1 <parm_decl 0x7ffff69d7300 a>>
77545.C:10:35 start: 77545.C:10:35 finish: 77545.C:10:35> 77545.C:10:35 start: 77545.C:10:35 finish: 77545.C:10:35>stmt <cleanup_stmt 0x7ffff6855bd0 type <void_type 0x7ffff687d000 void>
side-effects static tree_1arg 0 <statement_list 0x7ffff69d5f00 type <void_type 0x7ffff687d000 void>
head (nil) tail (nil) stmts >arg 1 <call_expr 0x7ffff68631c0 type <void_type 0x7ffff687d000 void>
side-effects nothrowfn <addr_expr 0x7ffff69d5ee0 type <pointer_type 0x7ffff69de0a8> constant arg 0 <function_decl 0x7ffff69db700 __comp_dtor >> arg 0 <nop_expr 0x7ffff69d5ea0 type <pointer_type 0x7ffff69d95e8>
arg 0 <addr_expr 0x7ffff69d5e80 type <pointer_type 0x7ffff69d95e8>
arg 0 <array_ref 0x7ffff6863188>>>> 77545.C:10:35 start: 77545.C:10:35 finish: 77545.C:10:35>> arg 1 <nop_expr 0x7ffff69e10a0 type <reference_type 0x7ffff69de690> arg 0 <addr_expr 0x7ffff69d5de0 type <pointer_type 0x7ffff69de1f8> arg 0 <var_decl 0x7ffff69df090 D.2323>>>>then, obviously, a bit later potential_constant_expression_1 stumbles into the CLEANUP_STMT among the statements in the STATEMENT_LIST we pass as ARG 0 of the COMPOUND_EXPR.
I have been investigating how we build and handle CLEANUP_STMTs in constexpr.c (see in particular the comment at the beginning of build_data_member_initialization) and wondering if simply returning true for it from potential_constant_expression_1 wouldn't be correct... Certainly passes testing.
Thanks for any feedback! Paolo. ///////////////////////////
Attachment:
patch_77545
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |