Hi!
As reported in the PR and can be seen on this simplified testcase
everywhere, the FEs sometimes call operand_equal_p e.g. on a SAVE_EXPR
that contains a BIND_EXPR in it, and if arg0 == arg1, operand_equal_p
can return non-zero on it.
The ICE is because inchash::add_expr is unprepared to hash some trees,
it handles just tcc_declaration, selected specific trees and expressions of
all kinds, the last one usually by just recursing on all their operands.
For BIND_EXPR, the last operand is usually a BLOCK which we ICE on though,
and the middle argument usually a STATEMENT_LIST that we ICE on as well.
The first hunk is just an optimization (but fixes the ICE anyway),
I think we really don't need to verify that a hash function for the same
argument always returns the same value. But I can imagine e.g.
a SAVE_EXPR of BIND_EXPR + var and var + the same SAVE_EXPR being compared
using operand_equal_p and there we wouldn't be equal at the top level and
still ICE.
The second hunk alone fixes the ICE too, by making sure we handle those
(just ignoring BLOCK and OMP_CLAUSE (the latter for now, if we find we want
to hash pre-OMP expansion trees too often we could adjust).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-04-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/70843
* fold-const.c (operand_equal_p): Don't verify hash value equality
if arg0 == arg1.
* tree.c (inchash::add_expr): Handle STATEMENT_LIST. Ignore BLOCK
and OMP_CLAUSE.
* gcc.dg/pr70843.c: New test.