[Bug c++/82952] Hang compiling with g++ -fsanitize=undefined -Wduplicated-branches

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Dec 8 10:14:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82952

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Yeah, indeed.  I'd say in this case the biggest problem is probably repeated
> traversal of SAVE_EXPRs in inchash::add_expr (which BTW doesn't seem to be
> something that operand_equal_p with OEP_LEXICOGRAPHICS handles).
> But generally you're right, even without SAVE_EXPRs with hundreds of nested
> COND_EXPRs the compile time complexity isn't tollerable either.
> So, shall we before those
>   /* Compute the hash of the then branch.  */
>   inchash::hash hstate0 (0);
>   inchash::add_expr (thenb, hstate0);
>   hashval_t h0 = hstate0.end ();
> 
>   /* Compute the hash of the else branch.  */
>   inchash::hash hstate1 (0);
>   inchash::add_expr (elseb, hstate1);
>   hashval_t h1 = hstate1.end ();
> walk thenb as well as elseb and count trees we've walked (and punt if seen
> more than some constant or PARAM trees)?  That could also punt if both
> numbers of trees are below the limit, but different (though
> inchash::add_expr as well as opernad_equal_p has some spots with STRIP_NOPS,
> which we'd no longer then recognize if different).

Some form of limiting would be nice.  At one point I thought that maybe
we should have an EXPR_HASH value sitting in the tree nodes ... but
another form of caching might work here, too.

Still the whole walk is too costly in extreme cases even when fixing the
hashing (which as far as I understand was done to make the actual compare
chepaer...)

> And/or add some optional hash table for remembering SAVE_EXPRs?  Though, I'd
> prefer not to slow down the normal add_expr...
> Shall we handle SAVE_EXPR in operand_equal_p if OEP_LEXICOGRAPHICS?

Experimenting with that makes sense.


More information about the Gcc-bugs mailing list