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

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

[ro at gcc dot gnu.org]

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

            Bug ID: 112863
           Summary: [14 regression] Many obj-c++ tests FAIL on macOS 12+
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: iains at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-apple-darwin2[1-3]

Between 20231013 and 20231027, man obj-c++.dg tests began to FAIL on macOS 12+:

FAIL: obj-c++.dg/basic.mm -fgnu-runtime (test for excess errors)
Excess errors:  
ld: warning: duplicate -rpath
'/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libstdc++-v3/src/.libs'
ignored

obj-c++.log shows that ALWAYS_OBJCXXFLAGS has several instances of -B/-L
.../libstdc++-v3/src/.libs.

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

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

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
which Xcode version produces this?
on Darwin23 with XC15.1 I get clean obj-c++ results
(but we should omit the duplicates anyway)

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
> which Xcode version produces this?

15.1.  Btw., I only see those failures on macOS 14, not earlier versions.

> on Darwin23 with XC15.1 I get clean obj-c++ results
> (but we should omit the duplicates anyway)

Indeed: even in they aren't harmful on other targets, they are just
wasted effort.

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

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-24
             Status|UNCONFIRMED                 |NEW
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 57203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57203&action=edit
patch under test


I still cannot reproduce these fails (I *can* see the duplicates, but the copy
of XC CLT 15.1 linker [dyld version] does not seem to report this warning.

So, I have "tested" this by checking visually that the duplicates are removed
(AFAICS), but it would be appreciated if you could confirm on your setup.

Also testing more widely.

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

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> ---
On macOS 11, everything is still fine.  On macOS 14, there's progress:

* Before your patch:

                === obj-c++ Summary ===

# of expected passes            2813
# of unexpected failures        378
# of expected failures          22
# of unsupported tests          71

* With the patch:

# of expected passes            3127
# of unexpected failures        72
# of expected failures          22
# of unsupported tests          71

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)
FAIL: obj-c++.dg/torture/strings/const-cfstring-3.mm   -O0  -fnext-runtime 
-Wno-objc-root-class (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'

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:
->  0x7ff819069f58 <+35>: movq   0x20(%rdi), %rcx
    0x7ff819069f5c <+39>: movq   %rcx, %rax
    0x7ff819069f5f <+42>: andq   %r15, %rax
    0x7ff819069f62 <+45>: testq  %rcx, %rcx
Target 0: (basic.exe) stopped.
(lldb) bt
* 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
    frame #1: 0x00007ff819059ded libobjc.A.dylib`map_images_nolock + 3856
    frame #2: 0x00007ff819058e62 libobjc.A.dylib`map_images + 69
    frame #3: 0x00007ff8190adc0f dyld`invocation function for block in
dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const*
const*, mach_header const* const*), void (*)(char const*, mach_header const*),
void (*)(char const*, mach_header const*), void (*)(mach_header const*, void*,
mach_header const*, void const*), void (*)(unsigned int,
_dyld_objc_notify_mapped_info const*), void (*)(_dyld_objc_notify_mapped_info
const*))::$_8::operator()() const + 682
    frame #4: 0x00007ff8190a59cc
dyld`dyld4::RuntimeLocks::withLoadersReadLock(void () block_pointer) + 46
    frame #5: 0x00007ff8190aac13
dyld`dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const*
const*, mach_header const* const*), void (*)(char const*, mach_header const*),
void (*)(char const*, mach_header const*), void (*)(mach_header const*, void*,
mach_header const*, void const*), void (*)(unsigned int,
_dyld_objc_notify_mapped_info const*), void (*)(_dyld_objc_notify_mapped_info
const*)) + 223
    frame #6: 0x00007ff8190d0960
dyld`dyld4::APIs::_dyld_objc_register_callbacks(_dyld_objc_callbacks const*) +
152
    frame #7: 0x00007ff8190588e4 libobjc.A.dylib`_objc_init + 675
    frame #8: 0x00007ff819281c00 libdispatch.dylib`_os_object_init + 13
    frame #9: 0x00007ff81928edf6 libdispatch.dylib`libdispatch_init + 364
    frame #10: 0x00007ff8262ef892 libSystem.B.dylib`libSystem_initializer + 222
    frame #11: 0x00007ff8190b7fca dyld`invocation function for block in
dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&)
const::$_0::operator()() const + 182
    frame #12: 0x00007ff8190f971f dyld`invocation function for block in
dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&,
dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int)
block_pointer, void const*) const + 241
    frame #13: 0x00007ff8190ed913 dyld`invocation function for block in
dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&,
bool, bool&) block_pointer) const + 543
    frame #14: 0x00007ff81909b07f
dyld`dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command
const*, bool&) block_pointer) const + 249
    frame #15: 0x00007ff8190ecadc dyld`dyld3::MachOFile::forEachSection(void
(dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 176
    frame #16: 0x00007ff8190f930a
dyld`dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&,
dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int)
block_pointer, void const*) const + 470
    frame #17: 0x00007ff8190b4cfc
dyld`dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 222
    frame #18: 0x00007ff8190be0ae
dyld`dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 30
    frame #19: 0x00007ff8190d6878 dyld`dyld4::APIs::runAllInitializersForMain()
+ 72
    frame #20: 0x00007ff8190a0241 dyld`dyld4::prepare(dyld4::APIs&,
dyld3::MachOAnalyzer const*) + 3397
    frame #21: 0x00007ff81909f31f dyld`start + 1839

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

[iains at gcc dot 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.

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

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2024-January
                   |                            |/644142.html

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
patch posted https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644142.html

the subsequent exposed fails should already be fixed by:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-January/397901.html (duplicate libs)
https://gcc.gnu.org/pipermail/gcc-cvs/2024-January/397902.html (segvs because
of over aligned meta-data).

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:bec7100445f07259d5df69c9f442ea72a90fc37e

commit r14-8733-gbec7100445f07259d5df69c9f442ea72a90fc37e
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Jan 24 08:05:41 2024 +0000

    testsuite, Objective-C++: Update link flags [PR112863].

    These regressions are caused by missing or duplicate runpaths which
    now fire linker warnings.

    We need to add options to locate libobjc (and on Darwin libobjc-gnu)
    along with libstdc++.
    Usually '-L' options are added to point to the relevant directories for
    the uninstalled libraries.

    In cases where libraries are available as both shared and convenience
    some additional checks are made.

    For some targets -static-xxxx options are handled by specs substitution
    and need a '-B' option rather than '-L'.  For Darwin, when embedded
    runpaths are in use (the default for all versions after macOS 10.11),
    '-B' is also needed to provide the runpath.

    When '-B' is used, this results in a '-L' for each path that exists (so
    that appending a '-L' as well is a needless duplicate).  There are also
    cases where tools warn for duplicates, leading to spurious fails.

            PR target/112863

    gcc/testsuite/ChangeLog:

            * lib/obj-c++.exp: Decide on whether to present -B or -L to
            reference the paths to uninstalled libobjc/libobjc-gnu and
            libstdc++ and use that to generate the link flags.

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

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
I suppose we are going to have to consider back porting this (and the fixes for
data layout), if we want to avoid the same problems on open branches.

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

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 regression] Many        |Many obj-c++ tests FAIL on
                   |obj-c++ tests FAIL on macOS |macOS 14
                   |14                          |

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
this is fixed on trunk, but still evaluating whether it's needed for macOS13/14
on older branches - (almost certainly for macOS14 + Xcode 15+).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.