Add flags to find libatomic in build-tree testing, fixing a catastrophic libgomp testsuite failure with `riscv*-*-linux*' targets, which imply `-latomic' with the `-pthread' GCC option, implied in turn by the `-fopenacc' and `-fopenmp' options, removing failures like:
.../bin/riscv64-linux-gnu-ld: cannot find -latomic collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: libgomp.c/../libgomp.c-c++-common/atomic-18.c (test for excess errors) Excess errors: .../bin/riscv64-linux-gnu-ld: cannot find -latomic UNRESOLVED: libgomp.c/../libgomp.c-c++-common/atomic-18.c compilation failed to produce executable and bringing overall test results for the `riscv64-linux-gnu' target (here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user emulation mode as the target board) from: === libgomp Summary === # of expected passes 90 # of unexpected failures 3267 # of expected failures 2 # of unresolved testcases 3247 # of unsupported tests 548 to: === libgomp Summary === # of expected passes 6834 # of unexpected failures 4 # of expected failures 4 # of unsupported tests 518 libgomp/ * testsuite/lib/libgomp.exp (libgomp_init): Add flags to find libatomic in build-tree testing. --- On Wed, 20 Nov 2019, Jakub Jelinek wrote: > > Why do you think it is important that it is only the relevant (i.e. > > `riscv*') targets that the directory providing newly-built libatomic is > > pointed at ? > > Such changes don't happen every day, no other port added it similarly to > riscv during the 2.5 years since riscv had it, and no port needed it ever > before. With unneeded -L options the log file is larger, one needs to > cut'n'paste more when trying to reproduce stuff etc. Fair enough. OK to apply? NB I've decided to use `ishost' rather than `istarget', and updated the existing comment accordingly, even though the triplets are always the same here, because GCC's target is libgomp's host, e.g.: Test run by macro on Wed Nov 20 00:39:23 2019 Target is riscv64-unknown-linux-gnu Host is riscv64-unknown-linux-gnu Build is x86_64-pc-linux-gnu === libgomp tests === Schedule of variations: qemu-user-lp64d Running target qemu-user-lp64d [...] -- and libgomp itself does not have a notion of a target (unlike e.g. libbfd). Consequently I suspect that: # Many hosts now default to a non-ASCII C locale, however, so # they can set a charset encoding here if they need. if { [ishost "*-*-cygwin*"] } { setenv LC_ALL C.ASCII setenv LANG C.ASCII } is incorrect for `dg-output' matching as it will execute for libgomp built for `*-*-cygwin*' rather than being necessarily verified on one, and therefore `isbuild' ought to be used here. Maciej Changes from v2: - Limit the change to `riscv*-*-linux*' targets. - Refer to the host rather than target within libgomp.exp as GCC's target is libgomp's host. Changes from v1: - Replaced references to "offload options" with "`-fopenacc' and `-fopenmp' options". --- libgomp/testsuite/lib/libgomp.exp | 14 ++++++++++++++ 1 file changed, 14 insertions(+) gcc-test-libgomp-atomic-lib-path.diff Index: gcc/libgomp/testsuite/lib/libgomp.exp =================================================================== --- gcc.orig/libgomp/testsuite/lib/libgomp.exp +++ gcc/libgomp/testsuite/lib/libgomp.exp @@ -174,6 +174,20 @@ proc libgomp_init { args } { # For build-tree testing, also consider the library paths used for builing. # For installed testing, we assume all that to be provided in the sysroot. if { $blddir != "" } { + # The `-fopenacc' and `-fopenmp' options imply `-pthread', and + # that implies `-latomic' on some hosts, so wire in libatomic + # build directories. + if [ishost "riscv*-*-linux*"] { + set shlib_ext [get_shlib_extension] + set atomic_library_path "${blddir}/../libatomic/.libs" + if { [file exists "${atomic_library_path}/libatomic.a"] + || [file exists \ + "${atomic_library_path}/libatomic.${shlib_ext}"] } { + lappend ALWAYS_CFLAGS \ + "additional_flags=-L${atomic_library_path}" + append always_ld_library_path ":${atomic_library_path}" + } + } global cuda_driver_include global cuda_driver_lib if { $cuda_driver_include != "" } {