This is the mail archive of the 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]

Re: extract_range_from_binary* cleanups for VRP

On 07/03/2018 08:16 AM, Martin Liška wrote:

It caused UBSAN errors:

$ cat ubsan.i
int a;
void d() { int c, b = 8 - a; }

$ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc -B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
../../gcc/tree-vrp.c:1715:26: runtime error: load of value 255, which is not a valid value for type 'bool'
     #0 0x3246ca2 in extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*, value_range*, value_range*) ../../gcc/tree-vrp.c:1715
     #1 0x34aa8b6 in vr_values::extract_range_from_binary_expr(value_range*, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/vr-values.c:794
     #2 0x34b45fa in vr_values::extract_range_from_assignment(value_range*, gassign*) ../../gcc/vr-values.c:1455
     #3 0x494cfd5 in evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool) ../../gcc/gimple-ssa-evrp-analyze.c:293
     #4 0x4942548 in evrp_dom_walker::before_dom_children(basic_block_def*) ../../gcc/gimple-ssa-evrp.c:139
     #5 0x487652b in dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:353
     #6 0x49470f9 in execute_early_vrp ../../gcc/gimple-ssa-evrp.c:310
     #7 0x49470f9 in execute ../../gcc/gimple-ssa-evrp.c:347
     #8 0x1fc4a0e in execute_one_pass(opt_pass*) ../../gcc/passes.c:2446
     #9 0x1fc8b47 in execute_pass_list_1 ../../gcc/passes.c:2535
     #10 0x1fc8b8e in execute_pass_list_1 ../../gcc/passes.c:2536
     #11 0x1fc8c68 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2546
     #12 0x2004c85 in do_per_function_toporder(void (*)(function*, void*), void*) ../../gcc/passes.c:1688
     #13 0x2005e9a in execute_ipa_pass_list(opt_pass*) ../../gcc/passes.c:2894
     #14 0xfcfa79 in ipa_passes ../../gcc/cgraphunit.c:2400
     #15 0xfcfa79 in symbol_table::compile() ../../gcc/cgraphunit.c:2536
     #16 0xfdc52a in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2696
     #17 0x25115e4 in compile_file ../../gcc/toplev.c:479
     #18 0x9278af in do_compile ../../gcc/toplev.c:2086
     #19 0x9278af in toplev::main(int, char**) ../../gcc/toplev.c:2221
     #20 0x92a79a in main ../../gcc/main.c:39
     #21 0x7ffff659c11a in __libc_start_main ../csu/libc-start.c:308
     #22 0x92a8c9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x92a8c9)

It's because neg_min_op0, or any other from:
       bool neg_min_op0, neg_min_op1, neg_max_op0, neg_max_op1;

I see.

After this spaghetti...

     if (vr0.type == VR_RANGE && vr1.type == VR_RANGE
	  && (TREE_CODE (min_op0) == INTEGER_CST
	      || (sym_min_op0
		  = get_single_symbol (min_op0, &neg_min_op0, &min_op0)))
	  && (TREE_CODE (min_op1) == INTEGER_CST
	      || (sym_min_op1
		  = get_single_symbol (min_op1, &neg_min_op1, &min_op1)))
	  && (!(sym_min_op0 && sym_min_op1)
	      || (sym_min_op0 == sym_min_op1
		  && neg_min_op0 == (minus_p ? neg_min_op1 : !neg_min_op1)))
	  && (TREE_CODE (max_op0) == INTEGER_CST
	      || (sym_max_op0
		  = get_single_symbol (max_op0, &neg_max_op0, &max_op0)))
	  && (TREE_CODE (max_op1) == INTEGER_CST
	      || (sym_max_op1
		  = get_single_symbol (max_op1, &neg_max_op1, &max_op1)))
	  && (!(sym_max_op0 && sym_max_op1)
	      || (sym_max_op0 == sym_max_op1
		  && neg_max_op0 == (minus_p ? neg_max_op1 : !neg_max_op1))))

...we would never actually use the neg*op* variables inside the adjust_symbolic_bound code.

Does this patch fix the problem on your end?

If so, OK for trunk?

	* tree-vrp.c (extract_range_from_binary_expr_1): Initialize
	neg_*_op* variables.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index c966334acbc..65865a7f5b6 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -1661,6 +1661,8 @@ extract_range_from_binary_expr_1 (value_range *vr,
       tree sym_max_op1 = NULL_TREE;
       bool neg_min_op0, neg_min_op1, neg_max_op0, neg_max_op1;
+      neg_min_op0 = neg_min_op1 = neg_max_op0 = neg_max_op1 = false;
       /* If we have a PLUS or MINUS with two VR_RANGEs, either constant or
 	 single-symbolic ranges, try to compute the precise resulting range,
 	 but only if we know that this resulting range will also be constant

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]