On Tue, Jul 3, 2018 at 7:49 PM Aldy Hernandez <al...@redhat.com> wrote:
>
>
>
> On 07/03/2018 08:16 AM, Martin Liška wrote:
> > Hi.
> >
> > 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?
OK. neg_* may be unset if the == INTEGER_CST check fires in which case
they are not implicitely negated.
Thanks,
Richard.
