[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

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

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #4)
> On macOS 11, everything is still fine.  On macOS 14, there's progress:

> The remaining failures fall into two categories:
> 
> FAIL: obj-c++.dg/encode-10.mm -fgnu-runtime (test for excess errors)
> FAIL: obj-c++.dg/encode-9.mm -fgnu-runtime (test for excess errors)
> FAIL: obj-c++.dg/encode-10.mm -fnext-runtime (test for excess errors)
> FAIL: obj-c++.dg/encode-9.mm -fnext-runtime (test for excess errors)

> 
> Those are all instances of
> 
> Excess errors:
> ld: warning: ignoring duplicate libraries: '-lobjc-gnu'
> 
> or
> 
> ld: warning: ignoring duplicate libraries: '-lobjc'

These are caused by the actual test adding -lobjc to the dg options (an easy
fix)...

> FAIL: obj-c++.dg/torture/strings/const-cfstring-3.mm   -O0  -fnext-runtime 
> -Wno-objc-root-class (test for excess errors)

^ This is actually grouped with the execution fails, the underlying cause is
the same.

> The remaining ones are all execution errors with -fnext-runtime.  E.g.
> obj-c++.dg/basic.mm SEGVs like
> 
>  thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x20)
>     frame #0: 0x00007ff819069f58 libobjc.A.dylib`readClass(objc_class*,
> bool, bool) + 35
> libobjc.A.dylib`readClass:

These appear to be caused by the compiler deciding that it's OK to bump the
alignment of constants that are TU-local to values > ABI alignment.

Unfortunately, although they _are_ TU-local, they also appear in named sections
- and it seems that the new linker has expectations that things in those
sections have ABI alignment. I am testing two fixes (one for CFStrings and one
for Objective-C meta-data) but because of that these need wide testing on
Darwin to make sure that they do not break earlier linkers....

It's possible that I could alter the binds local test to exclude objc.
metadata, but I'd prefer not to fiddle with that routine in stage 4... since
fallout is highly likely.