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 != "" } {