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 6E2D53857C66; Thu, 29 Jun 2023 16:12:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E2D53857C66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688055171;
	bh=Yst2Q/2Ar1l9atHRnYpuYU5r+wP4mlbQDi8p7augHMs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=kj51UdzXexqrLOZpV3HH5I75NwhAxLZlYQaElX3fEwpx+STjeRjp70y2mbR0Ytw7N
	 jr+g4cYpCCpcvSUh3VA0KH1HCDChOldfx5KaFMucfklBzpQlAyrcw2jyTRUXkM8nqd
	 ZrwftMc8KeX4cdVOtrW3OVAprMrz7RfjH1T/KT68=
From: "iains 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: Thu, 29 Jun 2023 16:12:51 +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: iains at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ppalka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110432-4-LsXCgxlcOE@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 #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #9)
> (In reply to Jonathan Wakely from comment #1)
> > Patrick, we talked about this and IIRC your suggestion was to move the
> > __has_attribute check into configure, so that it depends on GCC, not on
> > whichever compiler happens to include <iostream> later.
>=20
> Yes, sorry for letting this issue slip through the cracks.  It makes sense
> to fix this by simply disabling the <iostream> optimization on macOS as y=
ou
> suggested, and perhaps worry about a configure-time check only if it turns
> out another platform hits this issue.

do all the other (I guess non-embedded) platforms now have init priority
support?
(I think maybe something was added to AIX recently, and I suppose that Sola=
ris
when using bfd ld, at least would).

the solution is a reasonable band-aid (given that a patch to make init prio=
rity
work on Darwin is some way in the future).=