https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83435
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The ICE is because the vrp code sees INTEGER_CST with TREE_OVERFLOW set, which leaked in from: #0 make_int_cst (len=1, ext_len=1) at ../../gcc/tree.c:2262 #1 0x0000000001417a90 in build_new_int_cst (type=0x7fffefce42a0, cst=...) at ../../gcc/tree.c:1291 #2 0x0000000001417f8f in force_fit_type (type=0x7fffefce42a0, cst=..., overflowable=1, overflowed=true) at ../../gcc/tree.c:1381 #3 0x0000000000b907b6 in int_const_binop_1 (code=PLUS_EXPR, parg1=0x7fffefe3d7c8, parg2=0x7fffefcccd98, overflowable=1) at ../../gcc/fold-const.c:1113 #4 0x0000000000b907f2 in int_const_binop (code=PLUS_EXPR, arg1=0x7fffefe3d7c8, arg2=0x7fffefcccd98) at ../../gcc/fold-const.c:1121 #5 0x0000000000b90945 in const_binop (code=PLUS_EXPR, arg1=0x7fffefe3d7c8, arg2=0x7fffefcccd98) at ../../gcc/fold-const.c:1166 #6 0x0000000000b92fff in const_binop (code=PLUS_EXPR, type=0x7fffefce42a0, arg1=0x7fffefe3d7c8, arg2=0x7fffefcccd98) at ../../gcc/fold-const.c:1632 #7 0x0000000000bb1c35 in fold_binary_loc (loc=0, code=PLUS_EXPR, type=0x7fffefce42a0, op0=0x7fffefe3d7c8, op1=0x7fffefcccd98) at ../../gcc/fold-const.c:9146 #8 0x0000000000bc03bf in fold_build2_loc (loc=0, code=PLUS_EXPR, type=0x7fffefce42a0, op0=0x7fffefe3d7c8, op1=0x7fffefcccd98) at ../../gcc/fold-const.c:12202 #9 0x0000000002189695 in chrec_fold_plus_1 (code=PLUS_EXPR, type=0x7fffefce42a0, op0=0x7fffefe3d7c8, op1=0x7fffefcccd98) at ../../gcc/tree-chrec.c:359 #10 0x00000000021897b1 in chrec_fold_plus (type=0x7fffefce42a0, op0=0x7fffefe3d7c8, op1=0x7fffefcccd98) at ../../gcc/tree-chrec.c:392 #11 0x000000000218a6b1 in chrec_apply (var=2, chrec=0x7fffefe3c168, x=0x7fffefe3d7f8) at ../../gcc/tree-chrec.c:640 #12 0x00000000011e6b70 in compute_overall_effect_of_inner_loop (loop=0x7fffefe30220, evolution_fn=0x7fffefe3c168) at ../../gcc/tree-scalar-evolution.c:493 #13 0x00000000011ee41f in final_value_replacement_loop (loop=0x7fffefe30220) at ../../gcc/tree-scalar-evolution.c:3558 #14 0x00000000011aaf3c in try_create_reduction_list (loop=0x7fffefe30220, reduction_list=0x7fffffffdb10, oacc_kernels_p=false) at ../../gcc/tree-parloops.c:2727 #15 0x00000000011aca7b in parallelize_loops (oacc_kernels_p=false) at ../../gcc/tree-parloops.c:3337 #16 0x00000000011ace41 in (anonymous namespace)::pass_parallelize_loops::execute (this=0x30de7c0, fun=0x7fffefe28000) at ../../gcc/tree-parloops.c:3448 Wonder if final_value_replacement_loop shouldn't do: 3555 bool folded_casts; 3556 def = analyze_scalar_evolution_in_loop (ex_loop, loop, def, 3557 &folded_casts); 3558 def = compute_overall_effect_of_inner_loop (ex_loop, def); 3559 if (!tree_does_not_contain_chrecs (def) + 3560 || chrec_contains_symbols_defined_in_loop (def, ex_loop->num) 3561 /* Moving the computation from the loop may prolong life range 3562 of some ssa names, which may cause problems if they appear 3563 on abnormal edges. */ 3564 || contains_abnormal_ssa_name_p (def) 3565 /* Do not emit expensive expressions. The rationale is that 3566 when someone writes a code like 3567 3568 while (n > 45) n -= 45; 3569 3570 he probably knows that n is not large, and does not want it 3571 to be turned into n %= 45. */ 3572 || expression_expensive_p (def))