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 9E2BC385803D; Fri, 19 Jan 2024 14:48:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9E2BC385803D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705675728;
	bh=75OX5sUl9JgDgFFzhbFPNgteeNCnpni2UTwLujKmRrE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cy/nrioa/W8wd51I4J8dNUT0xNVNKt9iqv0zDOd0VWdJz21GR2orRcawNbmrdkds0
	 WpV10JVvuZu1x+rmDk0vKdJMe4eB5qE4wbToM8sHmsLJJI7Pnu25KZ7XOUuObSIcVT
	 utzOZW88z0y29brfL3sdmTGl8BnIKkxihX96flEg=
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL
 on macOS 12+
Date: Fri, 19 Jan 2024 14:48:47 +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: ro at CeBiTec dot Uni-Bielefeld.DE
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-112862-4-t54c6ftgbJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112862-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112862-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=3D112862

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot U=
ni-Bielefeld.DE> ---
> --- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
>> > Now I have a concern that we have instances of -Bpath/to/libsomething/=
.libs
>> > that are present to allow for specs substitution and we also need them=
 for
>> > providing run paths at test time.  BUT, we do not want duplicates
>> > (since, that
>> > triggers a different warning for some Xcode versions, and is
>> > inefficient anyway
>> > - albeit probably a very minor contribution to testing time).
>>=20
>> Still there is going to be an impact, even on non-Darwin.  However, this
>> duplication of -B and -L options is present all over the testsuite
>> already, just nobody cared to do something about it so far.  Those Xcode
>> 15 ld warnings my change this, though...
>
> Actually, since -B produces a -L for every -B directory that exists, if w=
e add
> -B we really ought to omit the -L if it's the same - otherwise we get use=
less
> duplicates on the link line.  Do you know of any exception to the B impli=
es L?

No.  TBH I only really knew about -B to find e.g. library-specific spec
files, not for libraries themselves.=