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 5388A3857B82; Wed,  7 Feb 2024 17:37:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5388A3857B82
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707327428;
	bh=C7+6lUCy+l1Ns54cMo5TGf77YLN9EP8D8oFslMtbHXw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=RbChDms+jxY9Op5DDJgHjrn06rCrrEEN4s4adUwarR4b165Ww69WjlvTfTbddtv81
	 Ja9MzLLtBSP9zraB+ieK9USzn9b66WRhD2hk+pV/ZevzsRlpVGkzvpGHSU+o4+5xaL
	 gd594aUTSHweg6xCW7D/p9eYsbMhHvCDOByJUziw=
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112397] Two persistent libstdc++ test failures on
 x86_64-apple-darwin
Date: Wed, 07 Feb 2024 17:37:07 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: testsuite-fail
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains 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: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-112397-4-3vx3O6RL7l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112397-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112397-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=3D112397

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-07
     Ever confirmed|0                           |1

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > The .cold symbol is created by gcc, I don't see any way to control its
> > visibility in the source. So maybe a target bug in the compiler, not a
> > library bug.
>=20
> Agreed its a target issue - it's a question of convincing the linker that
> the label is not reachable from a different TU if the implementation of t=
he
> non-cold symbol comes from that.

The problem is this:

We partition the function into hot/cold.

so we have

  weak definition
  hot
 ..... do stuff
 ... make a call

Landingpad1 OK... return
   epilogue_code:
   ....

Landingpad2 bad -> jump to error_case

   cold
error_case:
   ... do stuff
   jump epilogue_code.


=3D=3D=3D=3D

The linker says "oh you have a direct jump to that epilogue code in a weak
definition which would be broken if a different weak definition was chosen =
by
the dynamic linker".

On the face of it, the linker is correct ...
... but what it cannot see is that the only way to be executing the code th=
at
makes this jump is if it came from Landingpad2.

So actually, we do not have a real error - but I am not sure how we could go
about teaching the linker to DTRT (even if we could persuade Apple to do the
same for the new closed source one).

I'm tempted to suggest that we consider building libstdc++ with
`-fno-reorder-blocks-and-partition` and see if there's any measurable
performance decrease.

NOTE; that Darwin's linker (using subsections_by_symbols) is also able to
partition and reorder code without help from the compiler .. (although
whether/how much it does I"m not sure).

If there's a way to add that [-fno-reorder-blocks-and-partition] flag to th=
at
single source for Darwin-only, that would be a short-term workaround.=