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).