[Bug target/112862] New: [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[Bug target/112862] New: [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at gcc dot gnu.org]

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

            Bug ID: 112862
           Summary: [14 regression] gfortran.dg coarray 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, all gfortran.dg coarray tests started to FAIL
on macOS 12+:

dyld[93705]: Library not loaded: @rpath/libatomic.1.dylib
  Referenced from: <DADC9A43-F0F1-3D93-955D-C678CCEF4341>
/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/coarray_40.exe
  Reason: tried:
'/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/gcc/libatomic.1.dylib' (no
such file),
'/System/Volumes/Preboot/Cryptexes/OS/private/var/gcc/regression/master/14-gcc/build/gcc/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libgfortran/libatomic.1.dylib'
(no such file),
'/System/Volumes/Preboot/Cryptexes/OS/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libgfortran/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libgfortran/.libs/libatomic.1.dylib'
(no such file),
'/System/Volumes/Preboot/Cryptexes/OS/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libgfortran/.libs/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libquadmath/.libs/libatomic.1.dylib'
(no such file),
'/System/Volumes/Preboot/Cryptexes/OS/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libquadmath/.libs/libatomic.1.dylib'
(no such file), '/System/Volumes/Data/vol/gcc/lib/libatomic.1.dylib' (no such
file),
'/System/Volumes/Preboot/Cryptexes/OS/System/Volumes/Data/vol/gcc/lib/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/gcc/testsuite/gfortran/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/gcc/libatomic.1.dylib' (no
such file),
'/System/Volumes/Preboot/Cryptexes/OS/private/var/gcc/regression/master/14-gcc/build/gcc/libatomic.1.dylib'
(no such file),
'/private/var/gcc/regression/master/14-gcc/build/x86_64-apple-darwin23.1.0/libgfortran/libatomic.1.dylib'
(no such file), '/System/Volumes/Preboot/
FAIL: gfortran.dg/coarray_40.f90   -O0  execution test

Similar to PR target/112861, libatomic.1.dylib lives in .../libatomic/.libs
which isn't in the above directory list at all.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at gcc dot gnu.org]

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

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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?

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-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).
>> 
>> 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.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

works on x86_64 Sonoma with XC CLT 15.1
testing more widely

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> ---
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 ;-)

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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".

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

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

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

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 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: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.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

[Bug target/112862] gfortran.dg coarray tests FAIL on macOS 12+

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests
                   |coarray tests FAIL on macOS |FAIL on macOS 12+
                   |12+                         |

--- Comment #15 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 - so leaving open for now.

[Bug target/112862] gfortran.dg coarray tests FAIL on macOS 12+

[rguenth at gcc dot gnu.org]

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

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

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

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