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 F33423857C56; Thu, 25 Jan 2024 14:27:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F33423857C56
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1706192823;
	bh=l2aMNmwH9oEXrjoX2Yh/4JWKV3rMjmdW7fUrUvc3fCY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=LOyQqr8JzKeIsD8V22V8bSGHGZYhtzFHRt4JkIc/4ofUKtNciQlyfql+vpFQv3jDX
	 92q41P6eIc9Jq6aBTjm1zX7l+cZZJtdTE2LkEQu91fW+fl+TE/5sB5/QCACSa+g5d2
	 RaW3/FL4rhSRwigDkopyIsxtOqL6u18YoRq/2zI4=
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS
 14
Date: Thu, 25 Jan 2024 14:27:01 +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: iains at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-112863-4-isH4fpZTqG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112863-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112863-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=3D112863

--- 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:
>=20
> 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)

>=20
> Those are all instances of
>=20
> Excess errors:
> ld: warning: ignoring duplicate libraries: '-lobjc-gnu'
>=20
> or
>=20
> 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-runtim=
e=20
> -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
>=20
>  thread #1, queue =3D 'com.apple.main-thread', stop reason =3D EXC_BAD_AC=
CESS
> (code=3D1, address=3D0x20)
>     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 sect=
ions
- 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.=