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;