[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397

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.
> 
> 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 the
> 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.


====

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 that
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 that
single source for Darwin-only, that would be a short-term workaround.