https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91238
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hm, so what exactly should ADDR_EXPR of a CALL_EXPR code-gen to? The ICE
itself happens because add_expr, when traversing a CALL_EXPR does not
unset OEP_ADDRESS_OF when processing arguments (taking the address of the
CALL_EXPR doesn't mean we are taking the address of its arguments). Obviously
nobody thought we'd ever have an ADDR_EXPR of a CALL_EXPR and add_expr
should already assert on that... oddly enough we handle &COND_EXPR
so that would be precedent for a "fix":
Index: gcc/tree.c
===================================================================
--- gcc/tree.c (revision 273758)
+++ gcc/tree.c (working copy)
@@ -7996,6 +7996,7 @@ add_expr (const_tree t, inchash::hash &h
}
case CALL_EXPR:
+ flags &= ~OEP_ADDRESS_OF;
if (CALL_EXPR_FN (t) == NULL_TREE)
hstate.add_int (CALL_EXPR_IFN (t));
break;