From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 91600385E005; Sun, 29 Mar 2020 10:58:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91600385E005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585479515; bh=QsDoASZ5iVh7fu34rTY6UDg/bujPCz7zhFrrNChk5C8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=a73kot91fK6w5JiUkSwscqfogbXkM3pP4OgPOxj3coc+tv2Mo8BzrVzEjVWcRJH+Z ddu067Lha5pctgwuQSTs54C/c5QnfwUes4acvXzqMtzp0T3v227/wvQS1eWdel4IPi IGlXLZr+GCTx8+GVyUvOSjl/J4mAGPVI+nX/evWU= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails Date: Sun, 29 Mar 2020 10:58:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 10:58:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94359 --- Comment #6 from Iain Sandoe --- (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 wheth= er > 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. =3D=3D 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)=20 :( 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 =3D (generic_frame_t *)__builtin_malloc (sizeof (generic_frame_t)); f->a =3D actor; f->d =3D actor; f->_other_things =3D 0.0F; generic_handle_t h =3D {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 =3D get_handle (); generic_frame_t *t =3D h.fp; /* Use the TOC. */ t->other_things =3D 1.1F; (*t->a) ((void *)t); }=