this appears to be fixed; I get clean fortran testsuite results on (x86_64) Darwin21 and Darwin23.  Please could you check and either close this or post your Xcode version, configure line and OS version.

> --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
> this appears to be fixed; I get clean fortran testsuite results on (x86_64)
> Darwin21 and Darwin23.  Please could you check and either close this or post
> your Xcode version, configure line and OS version.

I'm still seeing this in last Friday's bootstraps:

macOS/Darwin versions		Xcode version

12.7.2 (21G1974)/21.6.0         14.2
13.6.3 (22G436)/22.6.0          14.3
14.2.1 (23C71)/23.2.0		15.1

The full configure line for macOS 14 is

/usr/local/bin/bash /vol/gcc/src/hg/master/darwin/configure --prefix=/vol/gcc --target=x86_64-apple-darwin23.2.0 --disable-multilib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --enable-libphobos --enable-objc-gc --with-target-bdw-gc-include=/vol/gcc/include --with-target-bdw-gc-lib=/vol/gcc/lib/amd64,i386=/vol/gcc/lib --with-gmp-include=/vol/gcc/include --with-gmp-lib=/vol/gcc/lib/amd64 --with-mpfr-include=/vol/gcc/include --with-mpfr-lib=/vol/gcc/lib/amd64 --with-mpc-include=/vol/gcc/include --with-mpc-lib=/vol/gcc/lib/amd64 --enable-languages=all,ada,obj-c++ --with-isl-include=/vol/gcc/include --with-isl-lib=/vol/gcc/lib/amd64 --with-zstd-include=/vol/gcc/include --with-zstd-lib=/vol/gcc/lib/amd64 --build=x86_64-apple-darwin23.2.0 --host=x86_64-apple-darwin23.2.0

The other two are equivalent.

When I check the coarray_40.exe binary on macOS 14, I find:

$ otool -L ./coarray_40.exe
./coarray_40.exe:
	@rpath/libatomic.1.dylib (compatibility version 4.0.0, current version 4.0.0)
	@rpath/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	@rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	@rpath/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
$ otool -l ./coarray_40.exe
[...]
Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/libatomic.1.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 4.0.0
compatibility version 4.0.0

but, unlike for the other libs, *no* corresponding LC_RPATH.

If I manually add the right -B arg
(-B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs)
to the command line, the missing LC_RPATH shows up and the excutable
runs successfully.

OK. So I realise the reason you see this and I wasn't: I have the habit of installing before running the testsuite.  When I test uninstalled, then I get the issue.

... the subsequent work reveals that we are not setting the "ENABLE_DARWIN_AT_RPATH" in gcc/site.exp.  Somehow an AC_SUBST has been dropped on the way.  However, that is actually fixable with a small change to gcc/Makefile.in.


... then we have to add -Bpath/to/libatomic/.libs conditionally on ENABLE_DARWIN_AT_RPATH (in gfortran.exp) (not hard since ENABLE_DARWIN_AT_RPATH is a global)

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).

So I think that gcc/lib/gfortran.exp needs to have the library -B/-L additions structured so that only one set gets added.  I'll draft a patch for you to try.

> --- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
> OK. So I realise the reason you see this and I wasn't: I have the habit of
> installing before running the testsuite.  When I test uninstalled, then I get
> the issue.

Right: I always avoid installing before testing to make extra certain to
test the freshly built bits and nothing else.

> 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).

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...

> So I think that gcc/lib/gfortran.exp needs to have the library -B/-L additions
> structured so that only one set gets added.  I'll draft a patch for you to try.

Great, thanks.

(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #4)
> > --- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
> > OK. So I realise the reason you see this and I wasn't: I have the habit of
> > installing before running the testsuite.  When I test uninstalled, then I get
> > the issue.
> 
> Right: I always avoid installing before testing to make extra certain to
> test the freshly built bits and nothing else.

I would not have that problem, since I always delete the previous install (otherwise its shared libraries could be found during the current build, since the GCC command lines usually include the installation paths).


> > 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).
> 
> 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 we add -B we really ought to omit the -L if it's the same - otherwise we get useless duplicates on the link line.  Do you know of any exception to the B implies L?

> --- 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).
>> 
>> 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 we add
> -B we really ought to omit the -L if it's the same - otherwise we get useless
> duplicates on the link line.  Do you know of any exception to the B implies L?

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

Created attachment 57202 [details]
patch under test

works on x86_64 Sonoma with XC CLT 15.1
testing more widely

Again tested on macOS 11 (unchanged) and 14.  On the latter, the previous failures
to find libatomic.1.dylib have been traded for

FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (test for excess errors)
Excess errors: 
ld: warning: duplicate -rpath '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/libatomic/.libs' ignored

This is definitely progress ;-)

(In reply to Rainer Orth from comment #8)
> Again tested on macOS 11 (unchanged) and 14.  On the latter, the previous
> failures
> to find libatomic.1.dylib have been traded for
> 
> FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (test for
> excess errors)
> Excess errors: 
> ld: warning: duplicate -rpath
> '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/
> libatomic/.libs' ignored
> 
> This is definitely progress ;-)

hmm I wonder where this is coming from .. as you noted there is a bit of a tendency in the testsuite to add stuff somewhat randomly.

> --- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
> (In reply to Rainer Orth from comment #8)
>> Again tested on macOS 11 (unchanged) and 14.  On the latter, the previous
>> failures
>> to find libatomic.1.dylib have been traded for
>> 
>> FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (test for
>> excess errors)
>> Excess errors: 
>> ld: warning: duplicate -rpath
>> '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/
>> libatomic/.libs' ignored
>> 
>> This is definitely progress ;-)
>
> hmm I wonder where this is coming from .. as you noted there is a bit of a
> tendency in the testsuite to add stuff somewhat randomly.

Right: I believe sometimes such duplication depends on whether you run
the test sequentially or in parallel.

FWIW, alloc_comp_1.f90 is linked like

spawn -ignore SIGHUP /private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../gfortran -B/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../ -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/ /vol/gcc/src/hg/master/darwin/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -fcoarray=single -O2 -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/ -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libgfortran/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libatomic/.libs -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/./libquadmath/.libs -lm -o ./alloc_comp_1.exe

In this case (by pure inspection) caf.exp includes both gfortran-dg.exp
and atomic-dg.exp.  The latter adds -B... itself.

(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #10)
> > --- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
> > (In reply to Rainer Orth from comment #8)
> >> Again tested on macOS 11 (unchanged) and 14.  On the latter, the previous
> >> failures
> >> to find libatomic.1.dylib have been traded for
> >> 
> >> FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (test for
> >> excess errors)
> >> Excess errors: 
> >> ld: warning: duplicate -rpath
> >> '/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/
> >> libatomic/.libs' ignored
> >> 
> >> This is definitely progress ;-)
> >
> > hmm I wonder where this is coming from .. as you noted there is a bit of a
> > tendency in the testsuite to add stuff somewhat randomly.
> 
> Right: I believe sometimes such duplication depends on whether you run
> the test sequentially or in parallel.
> 
> FWIW, alloc_comp_1.f90 is linked like
> 
> spawn -ignore SIGHUP
> /private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../../
> gfortran
> -B/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/../.
> ./
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libgfortran/
> /vol/gcc/src/hg/master/darwin/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.
> f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -fcoarray=single
> -O2
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libatomic/
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libatomic/.libs
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libgfortran/.libs
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libatomic/.libs
> -B/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.2.0/.
> /libquadmath/.libs -lm -o ./alloc_comp_1.exe
> 
> In this case (by pure inspection) caf.exp includes both gfortran-dg.exp
> and atomic-dg.exp.  The latter adds -B... itself.

Yes, indeed (FWIW: that target-supports check will only actually work [uninstalled] if the path to lib atomic is available, so it already depends on that being added in gfortran_init).

I'm removing the extra references to libatomic in gfortran.dg/dg.exp and caf.exp and then will test serial and parallel cases.  We can assert that the presence of the libraries as detected in gfortran_init is sufficient to state "target supports".

patch posted ; https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644141.html

The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

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

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

    testsuite, gfortran: Update link flags [PR112862].
    
    The regressions here are caused by two issues:
    1. In some cases there is no generated runpath for libatomic
    2. In other cases there are duplicate paths.
    
    This patch simplifies the addition of the options in the main
    gfortran exp and removes the duplicates elewhere.
    
    We need to add options to locate libgfortran and the dependent libs
    libquadmath (supporting REAL*16) and libatomic (supporting operations
    used by coarrays).  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/112862
    
    gcc/testsuite/ChangeLog:
    
            * gfortran.dg/coarray/caf.exp: Remove duplicate additions of
            libatomic handling.
            * gfortran.dg/dg.exp: Likewise.
            * lib/gfortran.exp: Decide on whether to present -B or -L to
            reference the paths to uninstalled libgfortran, libqadmath and
            libatomic and use that to generate the link flags.

I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.

this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - so leaving open for now.

GCC 14.1 is being released, retargeting bugs to GCC 14.2.

GCC 14.2 is being released, retargeting bugs to GCC 14.3.