[Bug debug/46150] [4.6 Regression] -fcompare-debug failure (length) with -fPIC -O2

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46150

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-10 21:08:05 UTC ---
Created attachment 22368
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22368
gcc46-pr46150.patch

Ugh, this is ugly.

We start having differences during ivopts.  The problem is that the
data->inv_expr_tab htab uses quite strict hash (iterative_hash_expr) which, as
it hashes stuff like TYPE_UID or DECL_UID, sometimes differs between -g and
-g0,
but very lax equality function (operand_equal_p).  The hash table is not
traversed, but as the equality function doesn't check hash value, depending on
the exact hash values we might or might not try to call the equality function
on expressions with different hash values.  In the testcase, there was
__result_14(D) + (-8 - (long unsigned int) &MEM[(struct _Vector_impl
*)__result_14(D) + 8B])
expression already in hash table and
(int *) __result_14(D) + (-8 - (long unsigned int) &MEM[(struct _Vector_impl
*)__result_14(D) + 8B])
expression being looked up.  In one case the equality function happened to be
run between these two and said their are equal, in the other case a new slot
has been created and that resulted later on in various small ivopts behavior
differences.

Attached patch fixes this testcase, but in theory it is not sufficient, we
could with very bad luck have two non-identical expressions that could in one
case (-g or -g0) hash to the same hash value and in the other case to different
values, but the lax operand_equal_p would still consider them to be equal.  So,
ideally we'd like to use some less lax comparison function which would match
the hashing function (basically compare all things that the hash function
hashes).  That said, I guess for 4.6 this patch ought to suffice (and I hope it
won't pessimize code too much, as sometimes we'll no longer hit matches that
happened by pure luck).