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 4CDCA3858C5F; Mon, 18 Mar 2024 15:33:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4CDCA3858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1710775981;
	bh=wvk2rfNQjHAmFcAJE1dgnXj4LhCVfF9bJ4SKsxCR/30=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=s90IC9Ebg4YxdSKpYbcnrPTj63MeRiiImCGc7lbiwfjy3XPTtE742fvEYUq3WETol
	 Qjj6gcDkW4tnwsiuNNVVDpGtD+VcBw4b9Q+Vl7R1Pme0raSgLDfwkrpXI+k/188Eq/
	 c2ZLOw9hFz23w0GW/n4aikK3nBFyHlmk0Mq6nANU=
From: "ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/114275] using std::thread within a templated function in a
 module fails to compile
Date: Mon, 18 Mar 2024 15:33:00 +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: 13.2.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppalka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114275-4-Nxg02iWuWk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114275-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114275-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=3D114275

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Nathaniel Shead from comment #4)
> I suspect there are a number of issues tied together here. Some of the
> things I've discovered so far:
>=20
> - 'tsubst_friend_class' calls 'lookup_name', which when called from a mod=
ule
> that doesn't export the class that was befriended fails to find it, and so
> it substitutes in a new instance of that type (which then later fails
> duplicate_decls).
>=20
> - Instantiating an elaborated type specifier doesn't attach it to the mod=
ule
> the containing template was declared in.
Nathan's comments from the threads

https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603288.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611215.html

seem relevant here.
>=20
> - Sometimes it seems that the container of a MK_local_friend decl is not
> always correctly streamed: in particular, in the comment 2 testcase the
> container streamed is a complete type on write, but on read is not comple=
te
> (TYPE_SIZE is null) and so is not properly read on stream-in in the first
> place.
Interesting, it looks like the definition does eventually get streamed in b=
ut
only after streaming in the MK_local_friend decl.  MK_field decls seem to g=
et
streamed in beforehand too.
>=20
> Additionally, it looks like you can hide some of the errors by making the
> importer a named module, because on instantiation it only calls
> 'duplicate_decls' on names imported from a partition.=