https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97157
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2020-09-22
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
3763 /* Don't ICE on FE specific trees, or their arguments etc.
3764 during operand_equal_p hash verification. */
3765 else if (!IS_EXPR_CODE_CLASS (tclass))
3766 gcc_assert (flags & OEP_HASH_CHECK);
(gdb) p tclass
$1 = tcc_type
(gdb) up
#2 0x0000000000df04db in operand_compare::hash_operand (
this=0x34ec118 <default_compare_instance>, t=<switch_stmt 0x7ffff6818118>,
3855 for (i = TREE_OPERAND_LENGTH (t) - 1; i >= 0; --i)
3856 hash_operand (TREE_OPERAND (t, i), hstate,
3857 i == 0 ? flags : sflags);
(gdb) p t
$2 = <switch_stmt 0x7ffff6818118>
and
/* Used to represent a 'switch' statement. The operands are
SWITCH_STMT_COND, SWITCH_STMT_BODY, SWITCH_STMT_TYPE, and
SWITCH_STMT_SCOPE, respectively. */
DEFTREECODE (SWITCH_STMT, "switch_stmt", tcc_statement, 4)
I guess it's simply that operand_equal/hash do not support FE tree codes.
Of course this particular stmt is badly designed with operands not being
"operands" ... instead those should have been SWITCH_STMT_TYPE and using
alternate fields in the tree.
I'd hate to add a langhook into those functions - the alternative to not
hash operands of lang specific tree codes would fix the ICE but will eventually
introduce unwanted collisions.
