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;

Reply via email to