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 8FB553858C83; Fri,  3 Mar 2023 17:06:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8FB553858C83
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677863212;
	bh=9/xg3nQO/IsbldzAIN+h/JGqeFcJqvfEeM/+avPIkTo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jRdAEd+9EwiYrAr2/JJ1DZhBncjjDVBTPQyKXdMH74F4/3fTeSbDBZ/lfVhynukiH
	 HRtlTAC3aDkpFm6Iu4LJgC8rPyvH9Zn0FniRcD+QrDxaaRVsXgStKRxUo6ETYvgtvK
	 SjjoPecT/K1De8sW62biHS+1NworkGKBQLPdZhjE=
From: "hubicka at ucw dot cz" <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:06:52 +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: hubicka at ucw dot cz
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-uNtewc5G4k@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 #8 from Jan Hubicka <hubicka at ucw dot cz> ---
>=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 t=
he
> coroutine body is outlined - so that has the original signature of the us=
er'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) th=
at are
> intended to be TU-local become visible across TUs in LTO; but those shoul=
d be
> the names of coroutine frame entries (i.e. fields in a structure, not
> themselves global symbols).

It is the type that we get warning on. So if it is never used to pass
data between translation units, the correct solution would be to put it
to the anoymous namespace.
(or avoid producing ODR name completely but that would lead to worse
code)

Honza=