[Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[seurer at linux dot vnet.ibm.com]

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

            Bug ID: 94359
           Summary: new test case
                    g++.dg/coroutines/torture/symmetric-transfer-00-basic.
                    C fails
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O0  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O1  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3 -g 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -Os  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C (test for excess
errors)

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-pedantic-errors -Wno-long-long -std=c++17 -fcoroutines
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./symmetric-transfer-00-basic.exe
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
In function 'void _Z8pingpongPKc.actor(pingpong(const
char*)::_Z8pingpongPKc.frame*)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:75:1:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
compiler exited with status 1

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-03-27
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
There are two cases here.

1) When the optimisation level is < 2 (where GCC does not normally tail-call).

 - in that case, the specific call [ which is in the tail position, and AFAIU
should be tail-callable ] is marked as TAIL_CALL, MUST_TAIL_CALL (hence the
complaint error: cannot tail-call: target is not able to optimize the call into
a sibling call, I suppose).

2) for O >= 2 where GCC would normally tail call anyway
 - for this, the coroutine code does not mark the cll specially, so for these
cases it indicates that the tail-call is not being made in "normal"
circumstance.

the function signature is

 void actor (void *)

and the codgen should be emitting an indirect call, followed by a void return 

(the indirect call is expanding __builtin_coro_resume() [expansion happens very
early in the ME].

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
it is not mandatory (for C++20 compliance) that the implementation provides
symmetric transfer - so it could be switched off - or XFAILed. 

However, users state that an impl. that can't do the symmetric transfers is not
useful in a number of important applications.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
Note1 : the 32b multilib works without any error.

Note2 : The dumps are gimple from symmetric-transfer-00-basic.C.020t.fixup_cfg1
which is the pass after all the coroutine-specific stuff is complete.

thus, For O0 (produces the error saying it can't tail call):

  <bb 25> :
actor.continue.ret:
  actor.continue = VIEW_CONVERT_EXPR<struct coroutine_handle>(D.38505);
  _38 = std::__n4835::coroutine_handle<void>::address (&actor.continue);
  _39 = MEM[(void (*<Te3>) (void *) *)_38];
  _39 (_38); [tail call] [must tail call]
  goto <bb 38>; [INV]

...

  <bb 38> :

  <bb 39> :
  actor.continue = {CLOBBER};

  <bb 40> :
<L55>:
  return;

====

for O2 (execute fails, because without the tail-call we overflow the stack).

  <bb 14> :
actor.continue.ret:
  frame_ptr->__resume_at = 6;
  _22 = &frame_ptr->__lv.1.1.aw;
  D.38734 = Loopy<int>::loopy_awaiter::await_suspend (_22,
frame_ptr->__self_h); [return slot optimization]
  actor.continue = VIEW_CONVERT_EXPR<struct coroutine_handle>(D.38734);
  _38 = std::__n4835::coroutine_handle<void>::address (&actor.continue);
  _39 = MEM[(void (*<Te3>) (void *) *)_38];
  _39 (_38); [tail call]
  goto <bb 21>; [INV]

...

  <bb 21> :
actor.suspend.ret:
<L63>:
  actor.continue = {CLOBBER};
  return;

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
so, it seems:

rs6000_function_ok_for_sibcall () 

calls   rs6000_decl_ok_for_sibcall ()

which gets a NULL decl and thus this returns false


      /* Under the AIX or ELFv2 ABIs we can't allow calls to non-local
         functions, because the callee may have a different TOC pointer to
         the caller and there's no way to ensure we restore the TOC when
         we return.  */
      if (!decl || DECL_EXTERNAL (decl) || DECL_WEAK (decl)
          || !(*targetm.binds_local_p) (decl))
        return false;

====

The signature of the callee is void (void *)

So not sure how to proceed here at the moment (I wonder if this works for PPC
on the clang impl).

The comment indicates that this is going to fail for AIX too as it stands.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #4)

> So not sure how to proceed here at the moment (I wonder if this works for
> PPC on the clang impl).

It does work for X86 (and ironically, on PPC Darwin too - where the fact that
we build a new "got" in each routine + no use of TOC means we can always tail
call).  Actually, I'm a bit suspicious of what happens in the case that two
coroutines are in different DSOs for X86.

apparently not:

[iains@gcc1-power7 llvm-90]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17
../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
-stdlib=libc++ -S
fatal error: error in backend: failed to perform tail call elimination on a
call site marked musttail

(the test case crashes the compiler for O>0).

[iains@gcc1-power7 llvm-10]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17
../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
-stdlib=libc++ -S
fatal error: error in backend: failed to perform tail call elimination on a
call site marked musttail

I'm going to discuss this with the coroutines paper authors - as to whether any
constraints had been considered.  Note, once again, that failure to implement
this does not make us non-conforming.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)

> I'm going to discuss this with the coroutines paper authors - as to whether
> any constraints had been considered.  Note, once again, that failure to
> implement this does not make us non-conforming.

coro paper author hadn't tested this configuration.

==
basically, the intent is that one can continue an arbitrary number
of coroutines, without overflowing the stack.  Maybe there's an alternate
pattern that we could construct that would allow this;  modulo the caller-
save of the TOC. Coroutine actor functions are marked with a flag, so we
do have a mechanism for handling them differently.

In the meantime, I guess this isn't going to work for PPC (AIX/powerpc64) 
:( and we have to XFAIL or switch it off.

/* A C equivalent of what's being done.  */
extern void actor (void *p);

/* This is how the public part of the coroutine frame ABI looks.  */
typedef struct __frame {
  void (*a) (void *);
  void (*d) (void *);
  float _other_things;
} generic_frame_t;

/* This is what a coroutine handle looks like.  */
typedef struct __handle {
  generic_frame_t *fp;
} generic_handle_t;

/* A fake call to get a handle...  */
__attribute__((__noinline__))
generic_handle_t get_handle (void)
{
  generic_frame_t *f = (generic_frame_t *)__builtin_malloc (sizeof
(generic_frame_t));
  f->a = actor;
  f->d = actor;
  f->_other_things = 0.0F;
  generic_handle_t h = {f};
  return h;
}

/* .. and part of coroutine state machine that wants to continue
   by executing another coroutine.
   X86 tail-calls this for O2+ (even for PIC) m32/m64
   PPC tail-calls for m32 (even for PIC), but not for ELFv2 m64.
   with the TOC reg caller-saved, perhaps there's no sequence that can
   work.
*/

void actor2 (void *p2)
{
  generic_handle_t h = get_handle ();

  generic_frame_t *t = h.fp;
  /* Use the TOC. */
  t->other_things = 1.1F;

   (*t->a) ((void *)t);
}

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org
               Host|powerpc64*-linux-gnu        |powerpc64*-linux-gnu,
                   |                            |sparc-sun-solaris2.11
             Target|powerpc64*-linux-gnu        |powerpc64*-linux-gnu,
                   |                            |sparc-sun-solaris2.11
              Build|powerpc64*-linux-gnu        |powerpc64*-linux-gnu,
                   |                            |sparc-sun-solaris2.11

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
I'm seeing the same failure on Solaris/SPARC (32 and 64-bit).

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #7)
> I'm seeing the same failure on Solaris/SPARC (32 and 64-bit).

Do you have any info on why the tail-call fails there?
(e.g. is it not possible to make an indirect tail-call in the ABI, as seems to
be the case for powerpc64 & AIX).

At present, having discussed with a couple of other folks, my plan (for stage
4) is to produce a target hook to allow targets to opt out.

For next stage 1, since the caller and the callee are both under our control
and it is known that the callee *must* be another coroutine 'actor' function it
might be possible to work around specific target constraints.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

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

--- Comment #9 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Rainer Orth from comment #7)
> > I'm seeing the same failure on Solaris/SPARC (32 and 64-bit).
> 
> Do you have any info on why the tail-call fails there?
> (e.g. is it not possible to make an indirect tail-call in the ABI, as seems
> to be the case for powerpc64 & AIX).

No.  I guess Eric (Cc'ed) is in a better position to answer that.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> No.  I guess Eric (Cc'ed) is in a better position to answer that.

Same as for PowerPC: look at the function_ok_for_sibcall predicate.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 48251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48251&action=edit
Patch for testing

coroutines: Fix compile error with symmetric transfers [PR94359]

For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine.  The current codegen marks these
resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
required for correctness, in the general case.

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.

The change here tests the target sibcall hook for the resume
expression and only marks it as requiring a tail call if that's
supported.

This doesn't fix the underlying problem; that really a solution is
needed to allow the tail-calls (or equivalent) to take place - but
that will be deferred until next stage 1.

The test case is 'xfail-run-if'd for the targets mentioned in this
PR since we still want to test that the compile proceeds without
error.  At compile-time we can't tell if missing the tail-call will
cause a specific code to fail, so that most likely a warning for this
case would produce a lot of false positives.


gcc/cp/ChangeLog:

2020-04-09  Iain Sandoe  <iain@sandoe.co.uk>

        PR c++/94359
        * coroutines.cc (build_actor_fn): Check that the target can
        support the resume tail-call before mandating it.

gcc/testsuite/ChangeLog:

2020-04-09  Iain Sandoe  <iain@sandoe.co.uk>

        PR c++/94359
        * g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
        Expect a run fail for targets without indirect tail-calls.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.0
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |c++

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
reclassifying as a c++ issue.

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:a126a1577ffcbf62d97723b35d343bdff014bb40

commit r10-7724-ga126a1577ffcbf62d97723b35d343bdff014bb40
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Tue Apr 14 20:37:12 2020 +0100

    coroutines: Fix compile error with symmetric transfers [PR94359]

    For symmetric transfers to work with C++20 coroutines, it is
    currently necessary to tail call the callee coroutine from resume
    method of the caller coroutine. The current codegen marks these
    resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
    required for correctness.

    Unfortunately, several targets have ABI constraints that prevent
    an indirect tail-call, which results in the PRs compile error.

    The change here tests the target sibcall hook for the resume
    expression and only marks it as requiring a tail call if that's
    supported.

    This doesn't fix the underlying problem; that really a solution is
    needed to allow the tail-calls (or equivalent) to take place - but
    that will be deferred until next stage 1.

    gcc/cp/ChangeLog:

    2020-04-14  Iain Sandoe  <iain@sandoe.co.uk>

            PR c++/94359
            * coroutines.cc (build_actor_fn): Check that the target can
            support the resume tailcall before mandating it.

    gcc/testsuite/ChangeLog:

    2020-04-14  Iain Sandoe  <iain@sandoe.co.uk>

            PR c++/94359
            * g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
            Expect a run fail for targets without arbitrary indirect
            tail-calls.

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[schwab@linux-m68k.org]

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

--- Comment #14 from Andreas Schwab <schwab@linux-m68k.org> ---
That completely breaks aarch64 (almost every coroutines test):

spawn -ignore SIGHUP /opt/gcc/gcc-20200415/Build/gcc/testsuite/g++/../../xg++
-B/opt/gcc/gcc-20200415/Build/gcc/testsuite/g++/../../
/opt/gcc/gcc-20200415/gcc/testsuite/g++.dg/coroutines/pr94528.C -mabi=lp64
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/opt/gcc/gcc-20200415/Build/aarch64-suse-linux/libstdc++-v3/include/aarch64-suse-linux
-I/opt/gcc/gcc-20200415/Build/aarch64-suse-linux/libstdc++-v3/include
-I/opt/gcc/gcc-20200415/libstdc++-v3/libsupc++
-I/opt/gcc/gcc-20200415/libstdc++-v3/include/backward
-I/opt/gcc/gcc-20200415/libstdc++-v3/testsuite/util -fmessage-length=0
-pedantic-errors -Wno-long-long -std=c++17 -fcoroutines -std=c++20
-fpreprocessed -w -S -o pr94528.s
/opt/gcc/gcc-20200415/gcc/testsuite/g++.dg/coroutines/pr94528.C: In function
'void
cppcoro::_ZN7cppcoro16make_shared_taskENS_4taskE.actor(cppcoro::make_shared_task(cppcoro::task)::_ZN7cppcoro16make_shared_taskENS_4taskE.frame*)':
/opt/gcc/gcc-20200415/gcc/testsuite/g++.dg/coroutines/pr94528.C:63:1: internal
compiler error: Segmentation fault
0xf2d113 crash_signal
        ../../gcc/toplev.c:328
0x12ac010 predefined_function_abi::id() const
        ../../gcc/function-abi.h:39
0x12ac010 aarch64_function_ok_for_sibcall
        ../../gcc/config/aarch64/aarch64.c:5278
0x70989f build_actor_fn
        ../../gcc/cp/coroutines.cc:2387
0x70c063 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
        ../../gcc/cp/coroutines.cc:3963
0x7682d7 finish_function(bool)
        ../../gcc/cp/decl.c:16941
0x84778b cp_parser_function_definition_after_declarator
        ../../gcc/cp/parser.c:28992
0x848653 cp_parser_function_definition_from_specifiers_and_declarator
        ../../gcc/cp/parser.c:28905
0x848653 cp_parser_init_declarator
        ../../gcc/cp/parser.c:20667
0x825237 cp_parser_simple_declaration
        ../../gcc/cp/parser.c:13731
0x853e3f cp_parser_declaration
        ../../gcc/cp/parser.c:13430
0x853be7 cp_parser_toplevel_declaration
        ../../gcc/cp/parser.c:13458
0x853be7 cp_parser_declaration_seq_opt
        ../../gcc/cp/parser.c:13306
0x853be7 cp_parser_namespace_body
        ../../gcc/cp/parser.c:19714
0x853be7 cp_parser_namespace_definition
        ../../gcc/cp/parser.c:19692
0x853f6f cp_parser_declaration
        ../../gcc/cp/parser.c:13410
0x8545bf cp_parser_translation_unit
        ../../gcc/cp/parser.c:4731
0x8545bf c_parse_file()
        ../../gcc/cp/parser.c:43961
0x9bfb57 c_common_parse_file()
        ../../gcc/c-family/c-opts.c:1190

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #14)
> That completely breaks aarch64 (almost every coroutines test):

apologies,

do you have any immediate idea why the aarch64_function_ok_for_sibcall
is failing there?

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[schwab@linux-m68k.org]

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

--- Comment #16 from Andreas Schwab <schwab@linux-m68k.org> ---
crtl != cfun

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:d0ce5baeb642bab57252c687cdf0ffb522e7a2a3

commit r10-7762-gd0ce5baeb642bab57252c687cdf0ffb522e7a2a3
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Thu Apr 16 14:17:51 2020 +0100

    coroutines: Back out mandate for tail-calls at O < 2 [PR94359]

    For symmetric transfers to work with C++20 coroutines, it is
    currently necessary to tail call the callee coroutine from resume
    method of the caller coroutine.  However there are several targets
    which don't support an indirect tail call to an arbitrary callee.

    Unfortunately, the target 'function_ok_for_sibcall' is not usable
    from the front end in all cases.  While it is possible to add a new
    hook to cover this circumstance, it is too late in the release
    cycle to be sure of getting the setting correct for all targets.

    So, this patch backs out the use of function_ok_for_sibcall () and
    the mandate of CALL_EXPR_MUST_TAIL_CALL from the symmetric
    transfer.

    Targets that can make indirect tail calls to arbitrary callees will
    still be able to make use of the symmetric transfer (without risking
    overrunning the stack) for optimization levels >= 2.

    The draft standard does not mandate unlimited symmetric transfers,
    so removing this is a QOI issue (albeit an important one) rather
    than a correctness one.

    The test is moved and adjusted so that it can be opted into by any
    target that supports the necessary tailcall.

    gcc/cp/ChangeLog:

    2020-04-16  Iain Sandoe  <iain@sandoe.co.uk>

            PR c++/94359
            * coroutines.cc (build_actor_fn): Back out use of
            targetm.function_ok_for_sibcall.  Do not mark the resume
            call as CALL_EXPR_MUST_TAIL_CALL.

    gcc/testsuite/ChangeLog:

    2020-04-16  Iain Sandoe  <iain@sandoe.co.uk>

            PR c++/94359
            * g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: Move..
            * g++.dg/coroutines/symmetric-transfer-00-basic.C: ..here and
            adjust to run at O2 for targets supporting the necessary tail
            call.

[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94794

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> ---
Fixed, PR 94794 tracks the requirement to add symmetric transfer in a more
general manner.