Re: RFA: how to fix Heisenbug

[Jeffrey A Law <law at redhat dot com>]

On Tue, 2004-12-21 at 15:47 -0800, Dale Johannesen wrote:
> I have a heisenbug that shows up as a crash in avail_expr_eq in
> the dominator optimizer; but the problem is lower down.  The
> basic problem is that there are two statements like this:
> 
> #   VUSE <TMT.1588_358>;
> D.68153_962 = __builtin_strlen (s_356);
> 
> #   VUSE <TMT.1588_358>;
> D.68154_963 = strlen (s_356);
> 
> A hash value is computed using iterative_hash_expr; this
> hashes in the pointer value of the callee function_decls, and
> computes different hashes for the statements,   The hash values are
> compared later using operand_equal_p, which has code
> to consider these the same:
> 
>      case tcc_declaration:
>        /* Consider __builtin_sqrt equal to sqrt.  */
> 
> The header comment for iterative_hash_expr says
> 
>     This function is intended to produce the same hash for expressions 
> which
>     would compare equal using operand_equal_p
> Not this time.
> 
> The obvious fix is to remove the code shown from operand_equal_p,
> but I thought I'd ask for advice at this point.
Arggh.  Yes, the obvious fix is to remove the special code from
operand_equal_p.  However, I don't know what downstream effects
that might have since I don't know offhand why operand_equal_p
special cases those builtins.

Alternately the hashing code would need to
consider calls to __builtin_strlen and strlen the same (and
similarly for any other special-cased builtin calls in
operand_equal_p.

It's vital that if two objects are equal according to the registered
equality function that they hash the same.


> Since the hash involves pointers, and there is a problem only
> if both hashes land in the same bucket, there's no way to make a
> reproducible example (in fact, the crash comes and goes
> depending on what options I use to build the compiler).
Yup, these are nasty.

jeff