[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:4e252e23d34932f13f39cc6544bf5c9379fa2a87

commit r11-7582-g4e252e23d34932f13f39cc6544bf5c9379fa2a87
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 9 16:44:27 2021 +0100

    c++: Fix coroutines on targetm.cxx.cdtor_return_this targets [PR99459]

    The r11-7528 build_co_await changes broke coroutines on arm*-linux-gnuabi,
    2780 ^FAIL.*coroutines/ in total.
    The problem is that arm is targetm.cxx.cdtor_return_this target where
    both ctors and dtors in the ABI return this pointer rather than
    void, and build_new_method_call_1 does:
                  else if (call != error_mark_node
                           && DECL_DESTRUCTOR_P (cand->fn)
                           && !VOID_TYPE_P (TREE_TYPE (call)))
                    /* An explicit call of the form "x->~X()" has type
                       "void".  However, on platforms where destructors
                       return "this" (i.e., those where
                       targetm.cxx.cdtor_returns_this is true), such calls
                       will appear to have a return value of pointer type
                       to the low-level call machinery.  We do not want to
                       change the low-level machinery, since we want to be
                       able to optimize "delete f()" on such platforms as
                       "operator delete(~X(f()))" (rather than generating
                       "t = f(), ~X(t), operator delete (t)").  */
                    call = build_nop (void_type_node, call);
    The new code in build_co_await relies on build_special_member_call
    returned expression being a CALL_EXPR, but due to the build_nop
    in there it is a NOP_EXPR around the CALL_EXPR.  It can't be stripped
    with STRIP_NOPS because void has different mode from the pointer mode.

    2021-03-09  Jakub Jelinek  <jakub@redhat.com>

            PR c++/99459
            * coroutines.cc (build_co_await): Look through NOP_EXPRs in
            build_special_member_call return value to find the CALL_EXPR.
            Simplify.