This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: how to fix Heisenbug
- From: Jeffrey A Law <law at redhat dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 21 Dec 2004 23:08:29 -0700
- Subject: Re: RFA: how to fix Heisenbug
- Organization: Red Hat, Inc
- References: <B6C0464B-53AA-11D9-9B34-000A95D7CD40@apple.com>
- Reply-to: 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