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.
