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]

Re: extract_range_from_binary* cleanups for VRP


On Tue, Jul 3, 2018 at 7:49 PM Aldy Hernandez <aldyh@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.


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