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 2752B38313B1; Tue, 27 Jun 2023 12:09:38 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2752B38313B1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1687867778;
	bh=JnoWj14eiJVaZPkFvNhUk+donQVccuf4pEE0P3A2Iz4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=dn+bSGK82iNRE3tKLnKwTLBT488FXPMlxet4XiJoj7xqbKUgzXdx4a16fiLsKcWos
	 FKGImrhDytXJIDfcNtHE5mVnVw2HxyHMd5eK4bLRVW7r5+X/8W+9pW5SJKiOhR1Wu+
	 wzco9GQ+QH/YvuJMN4g+llQTDA8fJcOdaW7V8trk=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/110432] macOS: Segmentation fault when using
 stdlibc++ from gcc 13.1 in combination with clang-16
Date: Tue, 27 Jun 2023 12:09:37 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 13.1.0
X-Bugzilla-Keywords: ABI
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: <bug-110432-4-EmRWxOo3KU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110432-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110432-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=3D110432

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Sascha Scandella from comment #2)
> I think this would also be a solution. Would this then be included in a
> future GCC 13.2?

Yes

(In reply to Iain Sandoe from comment #3)
> @Jonathan is there a patch for that proposed solution?

No

Thinking further about this, maybe we should just do:

#if !__has_attribute(__init_priority__) || defined __APPLE__

Because checking in the configure script would still give the wrong answer =
if
libstdc++ is built on macOS using Clang (which is unsupported, but people do
the darndest things). So maybe keep it simple and just don't try to use the
feature on macOS at all, ever.

(In reply to Iain Sandoe from comment #5)
> in slower time, we might consider the option of following clang's behavio=
ur
> for Darwin (possibly with a warning about the does-not-work-between-tus).

I don't understand why one would want to use the attribute only within a si=
ngle
TU, that doesn't seem useful.=