[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #14 from Iain Sandoe --- 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] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #13 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:e439c7827f5c5723fdd7df9c5fac55319db204af commit r14-8732-ge439c7827f5c5723fdd7df9c5fac55319db204af Author: Iain Sandoe Date: Wed Jan 24 08:05:30 2024 + 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- 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/644141.html --- Comment #12 from Iain Sandoe --- 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #11 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #10) > > --- Comment #9 from Iain Sandoe --- > > (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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Iain Sandoe --- > (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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #9 from Iain Sandoe --- (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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #8 from Rainer Orth --- 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #7 from Iain Sandoe --- Created attachment 57202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57202=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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Iain Sandoe --- >> > 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #5 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > > --- Comment #3 from Iain Sandoe --- > > 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #3 from Iain Sandoe --- 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #1 from Iain Sandoe --- 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+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0