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

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

[jakub at gcc dot gnu.org]

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

            Bug ID: 99459
           Summary: [11 Regression] Many coroutines regressions on
                    armv7hl-linux-gnueabi
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Seems likely one of the last weeks coroutines change broke a lot of coroutine
tests on 32-bit arm:
FAIL: g++.dg/coroutines/coro-missing-initial-suspend.C (test for excess errors)
FAIL: g++.dg/coroutines/pr94886-folly-3.C (internal compiler error)
FAIL: g++.dg/coroutines/pr94886-folly-3.C (test for excess errors)
FAIL: g++.dg/coroutines/pr95599.C (internal compiler error)
FAIL: g++.dg/coroutines/pr95599.C (test for excess errors)
FAIL: g++.dg/coroutines/pr95616-2.C (internal compiler error)
FAIL: g++.dg/coroutines/pr95616-2.C  (test for errors, line 28)
FAIL: g++.dg/coroutines/pr95616-2.C (test for excess errors)
FAIL: g++.dg/coroutines/pr95616-3.C (internal compiler error)
FAIL: g++.dg/coroutines/pr95616-3.C  (test for errors, line 19)
FAIL: g++.dg/coroutines/pr95616-3.C (test for excess errors)
FAIL: g++.dg/coroutines/pr95616-4.C (internal compiler error)
FAIL: g++.dg/coroutines/pr95616-4.C  (test for errors, line 20)
FAIL: g++.dg/coroutines/pr95616-4.C (test for excess errors)
...
FAIL: g++.dg/coroutines/torture/pr95003.C   -O1  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O1  (test for excess errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2  (test for excess errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -Os  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -Os  (test for excess errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: g++.dg/coroutines/torture/pr95003.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

Typical ICEs are like:
0x3c7de7 crash_signal
        ../../gcc/toplev.c:328
0x1e301b build_co_await
        ../../gcc/cp/coroutines.cc:871
0x1e52ab build_init_or_final_await
        ../../gcc/cp/coroutines.cc:2628
0x1e52ab coro_rewrite_function_body
        ../../gcc/cp/coroutines.cc:4023
0x1e52ab morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
        ../../gcc/cp/coroutines.cc:4166
0x7b045f finish_function(bool)
        ../../gcc/cp/decl.c:17207

or
0x3c7de7 crash_signal
        ../../gcc/toplev.c:328
0x1e34af build_co_await
        ../../gcc/cp/coroutines.cc:1034
0x1e52ab build_init_or_final_await
        ../../gcc/cp/coroutines.cc:2628
0x1e52ab coro_rewrite_function_body
        ../../gcc/cp/coroutines.cc:4023
0x1e52ab morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
        ../../gcc/cp/coroutines.cc:4166
0x7b045f finish_function(bool)
        ../../gcc/cp/decl.c:17207

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon <clyon at gcc dot gnu.org> ---
They appeared between r11-7517 (g:67f10d28f05fdae7ab25107d5be0b66b065b819b) and
r11-7537 (g:ceae9533826aabaf4c78d173c60e3bedeffc6955)

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

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/663801.html
r11-7517 was good, while
https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/663970.html
r11-7537 was already bad.
The coroutines.cc changes in between were r11-7527, r11-7528 and r11-7529.
I actually don't have an easy access to the box where this was built and don't
have preprocessed sources.

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
p debug_tree (dummy)
 <nop_expr 0x7fffe91ab380
    type <void_type 0x7fffea0610a8 void type_6 VOID
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea0610a8
        pointer_to_this <pointer_type 0x7fffea061150>>
    side-effects
    arg:0 <call_expr 0x7fffe917baf0
        type <pointer_type 0x7fffea061150 type <void_type 0x7fffea0610a8 void>
            public unsigned type_6 SI
            size <integer_cst 0x7fffea0501c8 constant 32>
            unit-size <integer_cst 0x7fffea0501e0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea061150
            pointer_to_this <pointer_type 0x7fffea06b1f8> reference_to_this
<reference_type 0x7fffe9997dc8>>
        side-effects nothrow
        fn <addr_expr 0x7fffe91ab360 type <pointer_type 0x7fffe970b5e8>
            constant arg:0 <function_decl 0x7fffe96d3000 __dt_comp >>
        arg:0 <addr_expr 0x7fffe91ab340 type <pointer_type 0x7fffe96d1888>
            arg:0 <var_decl 0x7fffe98f4c60 Fs>>
        ./example.cpp:317:1 start: ./example.cpp:317:1 finish:
./example.cpp:317:1>
    ./example.cpp:317:1 start: ./example.cpp:317:1 finish: ./example.cpp:317:1>
$1 = void

Guess the nop in there is added because of targetm.cxx.cdtor_returns_this.
The NOP_EXPR is created by:
              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);

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps:
2021-03-08  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.

--- gcc/cp/coroutines.cc.jj     2021-03-05 21:51:48.671185716 +0100
+++ gcc/cp/coroutines.cc        2021-03-08 10:53:13.187959339 +0100
@@ -868,6 +868,8 @@ build_co_await (location_t loc, tree a,
                = build_special_member_call (a, complete_dtor_identifier,
                                             NULL, a_type, LOOKUP_NORMAL,
                                             tf_none);
+             if (dummy && CONVERT_EXPR_P (dummy))
+               dummy = TREE_OPERAND (dummy, 0);
              dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0)
                            : NULL_TREE;
              if (dummy && coro_diagnose_throwing_fn (dummy))
@@ -1031,6 +1033,8 @@ build_co_await (location_t loc, tree a,
            = build_special_member_call (e_proxy, complete_dtor_identifier,
                                         NULL, o_type, LOOKUP_NORMAL,
                                         tf_none);
+         if (dummy && CONVERT_EXPR_P (dummy))
+           dummy = TREE_OPERAND (dummy, 0);
          dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0)
                        : NULL_TREE;
          if (dummy && coro_diagnose_throwing_fn (dummy))

?

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

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
It looks likely.

is there a 32b arm box on the cfarm?
I don't have access to one locally either (but maybe it will reproduce on a
cross...)

Both places in the crash logs are 

dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0)
                            : NULL_TREE;

where dummy is the return tree from a DTOR build, I guess that arm can return
something other than NULL_TREE for a failed build_special_member_call()?

will try to take a look this evening.

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

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> So perhaps:
> 2021-03-08  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.
> 
> --- gcc/cp/coroutines.cc.jj	2021-03-05 21:51:48.671185716 +0100
> +++ gcc/cp/coroutines.cc	2021-03-08 10:53:13.187959339 +0100
> @@ -868,6 +868,8 @@ build_co_await (location_t loc, tree a,
>  		= build_special_member_call (a, complete_dtor_identifier,
>  					     NULL, a_type, LOOKUP_NORMAL,
>  					     tf_none);
> +	      if (dummy && CONVERT_EXPR_P (dummy))
> +		dummy = TREE_OPERAND (dummy, 0);
>  	      dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0)
>  			    : NULL_TREE;
>  	      if (dummy && coro_diagnose_throwing_fn (dummy))
> @@ -1031,6 +1033,8 @@ build_co_await (location_t loc, tree a,
>  	    = build_special_member_call (e_proxy, complete_dtor_identifier,
>  					 NULL, o_type, LOOKUP_NORMAL,
>  					 tf_none);
> +	  if (dummy && CONVERT_EXPR_P (dummy))
> +	    dummy = TREE_OPERAND (dummy, 0);
>  	  dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0)
>  			: NULL_TREE;
>  	  if (dummy && coro_diagnose_throwing_fn (dummy))
> 
> ?

looks reasonable to me - but I have no way to test it at present.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm
           Priority|P3                          |P1

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

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
would STRIP_NOPS() be more general?

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think STRIP_NOPS strips the nops only if the outer and inner type have the
same TYPE_MODE, that is not the case here, the outer type is VOID_TYPE, the
inner type is some POINTER_TYPE.

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

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-08
             Status|UNCONFIRMED                 |NEW

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
I could reproduce this with an arm-linux-gnueabi cross (using a sysroot from a
linaro 7.5 distribution).

The patch at comment #4 works for me for compile tests.
I have no setup to do exec. tests.

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

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm bootstrapping/regtesting it using a package build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=63330796
but it will take about 9 more hours to complete given the average arm build
times).

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

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

[cvs-commit at gcc dot 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.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.