From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 021963858CDB; Fri,  3 Mar 2023 17:10:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 021963858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677863452;
	bh=O+ODvTxv9aTQSlBEehhjVaOckzQiqE5fxmFGeeMVcqs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jHPJwLJiJIsLLR32bLSLfsVeI+qwV0efUvcxPhVQBPl6/iWxa+jjTrPj+tRrLLTjD
	 l0Mr9jsdldUkYMKNOm2JgAHwctMmjO7zJeYIvwTwXE0FTkbc/rOESQAMzM67261dUS
	 xrP43iULOPtir6XYB0gaFMj08V0XQWk6ZHAWifCk=
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/101118] coroutines: unexpected ODR warning for coroutine
 frame type in LTO builds
Date: Fri, 03 Mar 2023 17:10:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 11.1.0
X-Bugzilla-Keywords: C++-coroutines, diagnostic, lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: <bug-101118-4-YjXrOcVUXI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101118-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101118-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> >=20
> > the synthesised functions (actor, destroy) are intended to be TU-local.
> > the ramp function is what remains of the user's original function after=
 the
> > coroutine body is outlined - so that has the original signature of the =
user's
> > function.
> >=20
> > We do use counters to generate local symbol names for frame-promoted
> > temporaries, so I suppose that there is a possibility that the name(s) =
that are
> > intended to be TU-local become visible across TUs in LTO; but those sho=
uld be
> > the names of coroutine frame entries (i.e. fields in a structure, not
> > themselves global symbols).
>=20
> It is the type that we get warning on.=20

The frame type itself .. I see...

> So if it is never used to pass
> data between translation units, the correct solution would be to put it
> to the anoymous namespace.

... OK .. that makes sense; the frame is type-erased for calls from other T=
Us,
so that this seems the right solution.

> (or avoid producing ODR name completely but that would lead to worse
> code)

Yeah, we need the name for the outlined function(s) so that there is
opportunity to inline there,

>=20
> Honza=