Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c

[law at redhat dot com]

In message <1055448430.13007.78.camel@frodo.toronto.redhat.com>, Diego Novillo 
writes:
 >OK, the failure only happens with checking disabled.  Also, don't try to
 >use -save-temps, as that will also mask the bug.  I've seen something
 >like this when I first implemented redundancy elimination, and, yes we
 >are getting operand_equal_p() return false for self-comparisons.
 >
 >The table is expanded a few times (85 calls to htab_expand).
 >
 >This is the element that fails:
 >
 >
 >Program received signal SIGSEGV, Segmentation fault.
 >htab_remove_elt (htab=0x108ae828, element=0x30b2b340)
 >    at /home/dnovillo/tree-ssa/src.ppc/libiberty/hashtab.c:570
 >570       if (*slot == EMPTY_ENTRY)
 >(gdb) p (tree)element
 >$3 = (union tree_node *) 0x30b2b340
 >(gdb) pt
 > <modify_expr 0x30b2b340
 >    type <pointer_type 0x307e2500
 >        type <array_type 0x306faf80 type <union_type 0x306fa900 rtunion>
 >            asm_written DI
 >            size <integer_cst 0x301f4980 constant 64>
 >            unit size <integer_cst 0x301f6080 constant 8>
 >            align 64 symtab 812639744 alias set 17 domain <integer_type 0x301
 >f7400>
 >            pointer_to_this <pointer_type 0x307e2500>>
 >        unsigned SI
 >        size <integer_cst 0x301f6140 constant 32>
 >        unit size <integer_cst 0x301f6200 constant 4>
 >        align 32 symtab 0 alias set -1>
 >    side-effects
 >    arg 0 <ssa_name 0x30d7f500 type <pointer_type 0x307e2500>
 >       >
 >    arg 1 <nop_expr 0x30a16ac0 type <pointer_type 0x307e2500>
 >
 >        arg 0 <ssa_name 0x30cfd6e0 type <pointer_type 0x3040ec80 rtx>
 >           >>
 >    insn-extract.c:1546>
 >(gdb) print operand_equal_p(element,element,0)
Ugh.  We want to compare the RHS of the modify expr.  Try this instead

print operand_equal_p (element->exp->operands[1], element->exp->operands[1], 0)

And let me know if those compare equal.  They should given the tree dump
you provided.  This would be an indicator that the underlying problem isn't
incorrect objects in the hash table, but instead different hash values for
objects which are equal according to operand_equal_p.  This can cause
objects to be "unfindable" in the hash table, which leads to segfaults
like you're seeing.

See my message from a couple weeks ago entitled "Questions about hashtab.c
behavior".  It went to Vlad, Jason, Andrew and you. I can resend it if
you're interested in the details.  The number of things that have to
happen "just so" are pretty amazing, but it does happen.

Interestingly enough, I'm about to check in a change which fixes one case
I've tripped over where we can get different has values for equal objects.
The reason I mention it is that it also involves NOP conversions.  We hash
(via iterative_hash_object) on the TREE_TYPE of the conversion which hashes
on the address of the TYPE.  Which easily leads to this class of problems.

Jeff