* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
@ 2020-03-27 17:13 ` iains at gcc dot gnu.org
2020-03-27 17:16 ` iains at gcc dot gnu.org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-27 17:13 UTC (permalink / raw)
To: gcc-bugs
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].
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
2020-03-27 17:13 ` [Bug target/94359] " iains at gcc dot gnu.org
@ 2020-03-27 17:16 ` iains at gcc dot gnu.org
2020-03-27 21:48 ` iains at gcc dot gnu.org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-27 17:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
2020-03-27 17:13 ` [Bug target/94359] " iains at gcc dot gnu.org
2020-03-27 17:16 ` iains at gcc dot gnu.org
@ 2020-03-27 21:48 ` iains at gcc dot gnu.org
2020-03-28 9:18 ` iains at gcc dot gnu.org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-27 21:48 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (2 preceding siblings ...)
2020-03-27 21:48 ` iains at gcc dot gnu.org
@ 2020-03-28 9:18 ` iains at gcc dot gnu.org
2020-03-28 16:10 ` iains at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-28 9:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (3 preceding siblings ...)
2020-03-28 9:18 ` iains at gcc dot gnu.org
@ 2020-03-28 16:10 ` iains at gcc dot gnu.org
2020-03-29 10:58 ` iains at gcc dot gnu.org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-28 16:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (4 preceding siblings ...)
2020-03-28 16:10 ` iains at gcc dot gnu.org
@ 2020-03-29 10:58 ` iains at gcc dot gnu.org
2020-04-02 11:09 ` ro at gcc dot gnu.org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-03-29 10:58 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (5 preceding siblings ...)
2020-03-29 10:58 ` iains at gcc dot gnu.org
@ 2020-04-02 11:09 ` ro at gcc dot gnu.org
2020-04-02 11:26 ` iains at gcc dot gnu.org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ro at gcc dot gnu.org @ 2020-04-02 11:09 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (6 preceding siblings ...)
2020-04-02 11:09 ` ro at gcc dot gnu.org
@ 2020-04-02 11:26 ` iains at gcc dot gnu.org
2020-04-02 11:51 ` ro at gcc dot gnu.org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-02 11:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (7 preceding siblings ...)
2020-04-02 11:26 ` iains at gcc dot gnu.org
@ 2020-04-02 11:51 ` ro at gcc dot gnu.org
2020-04-02 17:38 ` ebotcazou at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ro at gcc dot gnu.org @ 2020-04-02 11:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (8 preceding siblings ...)
2020-04-02 11:51 ` ro at gcc dot gnu.org
@ 2020-04-02 17:38 ` ebotcazou at gcc dot gnu.org
2020-04-09 20:40 ` iains at gcc dot gnu.org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2020-04-02 17:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (9 preceding siblings ...)
2020-04-02 17:38 ` ebotcazou at gcc dot gnu.org
@ 2020-04-09 20:40 ` iains at gcc dot gnu.org
2020-04-09 20:41 ` iains at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-09 20:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (10 preceding siblings ...)
2020-04-09 20:40 ` iains at gcc dot gnu.org
@ 2020-04-09 20:41 ` iains at gcc dot gnu.org
2020-04-14 18:58 ` [Bug c++/94359] " iains at gcc dot gnu.org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-09 20:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (11 preceding siblings ...)
2020-04-09 20:41 ` iains at gcc dot gnu.org
@ 2020-04-14 18:58 ` iains at gcc dot gnu.org
2020-04-14 19:44 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-14 18:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (12 preceding siblings ...)
2020-04-14 18:58 ` [Bug c++/94359] " iains at gcc dot gnu.org
@ 2020-04-14 19:44 ` cvs-commit at gcc dot gnu.org
2020-04-15 11:50 ` schwab@linux-m68k.org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-14 19:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (13 preceding siblings ...)
2020-04-14 19:44 ` cvs-commit at gcc dot gnu.org
@ 2020-04-15 11:50 ` schwab@linux-m68k.org
2020-04-15 13:03 ` iains at gcc dot gnu.org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: schwab@linux-m68k.org @ 2020-04-15 11:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (14 preceding siblings ...)
2020-04-15 11:50 ` schwab@linux-m68k.org
@ 2020-04-15 13:03 ` iains at gcc dot gnu.org
2020-04-15 13:24 ` schwab@linux-m68k.org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-15 13:03 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (15 preceding siblings ...)
2020-04-15 13:03 ` iains at gcc dot gnu.org
@ 2020-04-15 13:24 ` schwab@linux-m68k.org
2020-04-16 23:02 ` cvs-commit at gcc dot gnu.org
2020-04-27 10:23 ` iains at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: schwab@linux-m68k.org @ 2020-04-15 13:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #16 from Andreas Schwab <schwab@linux-m68k.org> ---
crtl != cfun
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (16 preceding siblings ...)
2020-04-15 13:24 ` schwab@linux-m68k.org
@ 2020-04-16 23:02 ` cvs-commit at gcc dot gnu.org
2020-04-27 10:23 ` iains at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-16 23:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
2020-03-27 16:30 [Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails seurer at linux dot vnet.ibm.com
` (17 preceding siblings ...)
2020-04-16 23:02 ` cvs-commit at gcc dot gnu.org
@ 2020-04-27 10:23 ` iains at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: iains at gcc dot gnu.org @ 2020-04-27 10:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread