[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

Sebastian Pop sebpop@gmail.com
Sun Jun 24 10:11:00 GMT 2007


On 6/24/07, Sebastian Pop <spop@gcc.gnu.org> wrote:
> Unfortunately I haven't seen the suggestion of Håkan Hjort to also
> implement the fold of ~a + a ==> ~0.  I could add a new patch for this
> one too in the next bootstrap if the current patch still has issues.
>

I just realized that we already implement this:
	  /* ~X + X is -1.  */
	  /* X + ~X is -1.  */

But, in our case, when we arrive at this point, it is useless because
it uses operand_equal_p, so the above test fails, and we don't enter
that code:

	  /* ~X + X is -1.  */
	  if (TREE_CODE (arg0) == BIT_NOT_EXPR
	      && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
	      && !TYPE_OVERFLOW_TRAPS (type))
	    {
	      t1 = build_int_cst_type (type, -1);
	      return omit_one_operand (type, t1, arg1);
	    }

and at that point we have:

(gdb) call debug_tree (arg0)
 <bit_not_expr 0xb7cd67c0
    type <integer_type 0xb7c2c000 unsigned int public unsigned sizetype SI
        size <integer_cst 0xb7c1d658 constant invariant 32>
        unit size <integer_cst 0xb7c1d444 constant invariant 4>
        align 32 symtab 0 alias set -1 canonical type 0xb7c320d8
precision 32 min <integer_cst 0xb7c1d674 0> max <integer_cst
0xb7c1dc08 -1>>

    arg 0 <nop_expr 0xb7cd65a0 type <integer_type 0xb7c2c000 unsigned int>

        arg 0 <ssa_name 0xb7cd230c type <integer_type 0xb7c2c2f4 int>
            volatile visited var <var_decl 0xb7cce000 i> def_stmt
<nop_expr 0xb7cc5940>
            version 4>>>
(gdb) call debug_tree (arg1)
 <ssa_name 0xb7cd230c
    type <integer_type 0xb7c2c2f4 int sizes-gimplified public SI
        size <integer_cst 0xb7c1d658 constant invariant 32>
        unit size <integer_cst 0xb7c1d444 constant invariant 4>
        align 32 symtab 0 alias set 2 canonical type 0xb7c2c2f4
precision 32 min <integer_cst 0xb7c1d604 -2147483648> max <integer_cst
0xb7c1d620 2147483647>
        pointer_to_this <pointer_type 0xb7c32798>>
    volatile visited var <var_decl 0xb7cce000 i> def_stmt <nop_expr 0xb7cc5940>
    version 4>


So this just looks like we want to improve operand_equal_p, and not
touch the folder this time.  Probably we can implement one more flag
for stripping nop conversions of operands.

Sebastian



More information about the Gcc-patches mailing list