Bug 83435 - [8 Regression] ICE in set_value_range, at tree-vrp.c:211
Summary: [8 Regression] ICE in set_value_range, at tree-vrp.c:211
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 8.0
: P1 normal
Target Milestone: 8.0
Assignee: Richard Biener
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2017-12-15 05:00 UTC by Arseny Solokha
Modified: 2018-01-11 13:43 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-12-15 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arseny Solokha 2017-12-15 05:00:15 UTC
gcc-8.0.0-alpha20171210 snapshot (r255534) ICEs when compiling the following snippet w/ -O1 (-Os, -O2, -O3, -Ofast) -ftree-parallelize-loops=2 -floop-parallelize-all:

int yj, ax;

void
gf (signed char mp)
{
  int *dh = &yj;

  for (;;)
    {
      signed char sb;

      for (sb = 0; sb < 1; sb -= 8)
        {
        }

      mp &= mp <= sb;
      if (mp == 0)
        dh = &ax;
      mp = 0;
      *dh = 0;
    }
}

% gcc-8.0.0-alpha20171210 -O1 -ftree-parallelize-loops=2 -floop-parallelize-all -c jv3h3lvo.c
during GIMPLE pass: dom
jv3h3lvo.c: In function 'gf':
jv3h3lvo.c:4:1: internal compiler error: in set_value_range, at tree-vrp.c:211
 gf (signed char mp)
 ^~
0x7645b3 set_value_range(value_range*, value_range_type, tree_node*, tree_node*, bitmap_head*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/tree-vrp.c:211
0xf7944d vr_values::extract_range_for_var_from_comparison_expr(tree_node*, tree_code, tree_node*, tree_node*, value_range*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/vr-values.c:634
0x13eb9a0 evrp_range_analyzer::try_find_new_range(tree_node*, tree_node*, tree_code, tree_node*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/gimple-ssa-evrp-analyze.c:87
0x13ec7d6 evrp_range_analyzer::record_ranges_from_incoming_edge(basic_block_def*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/gimple-ssa-evrp-analyze.c:196
0x13ecd1a evrp_range_analyzer::enter(basic_block_def*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/gimple-ssa-evrp-analyze.c:73
0xe17a06 dom_opt_dom_walker::before_dom_children(basic_block_def*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/tree-ssa-dom.c:1411
0x13d2147 dom_walker::walk(basic_block_def*)
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/domwalk.c:308
0xe1801f execute
	/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171210/work/gcc-8-20171210/gcc/tree-ssa-dom.c:704
Comment 1 Jakub Jelinek 2017-12-15 08:29:39 UTC
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))
Comment 2 Jakub Jelinek 2017-12-15 08:32:37 UTC
or something similar (or should it walk the whole def for TREE_OVERFLOWs)?
Or shall this be caught earlier during SCEV computations?  Not taking this PR, SCEV is not something I have much experience with.
Comment 3 Richard Biener 2018-01-10 15:14:25 UTC
Mine.
Comment 4 Richard Biener 2018-01-11 09:22:51 UTC
I have a patch robustifying VRP.  Yes, we don't want to leak overflow constants into the IL but we're not there yet and I'd rather have this done in a robust way but couldn't yet thing of one (like not creating them in the first place when
in GIMPLE form?!  But we have to audit our codebase on where TREE_OVERFLOW is
expected to be set - IIRC that's mostly FEs, but only "mostly"...).
Comment 5 Richard Biener 2018-01-11 13:42:50 UTC
Fixed.
Comment 6 Richard Biener 2018-01-11 13:43:01 UTC
Author: rguenth
Date: Thu Jan 11 13:42:29 2018
New Revision: 256535

URL: https://gcc.gnu.org/viewcvs?rev=256535&root=gcc&view=rev
Log:
2018-01-11  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/83435
	* graphite.c (canonicalize_loop_form): Ignore fake loop exit edges.
	* graphite-scop-detection.c (scop_detection::get_sese): Likewise.
	* tree-vrp.c (add_assert_info): Drop TREE_OVERFLOW if they appear.

	* gcc.dg/graphite/pr83435.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/graphite/pr83435.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/graphite-scop-detection.c
    trunk/gcc/graphite.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c