public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@wdc.com>
To: Jakub Jelinek <jakub@redhat.com>, gcc-patches@gcc.gnu.org
Subject: [PATCH v2] libgomp/test: Add flags to find libatomic in build-tree testing
Date: Tue, 19 Nov 2019 23:18:00 -0000	[thread overview]
Message-ID: <alpine.LFD.2.21.1911181735050.13542@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <20191118153213.GZ4650@tucnak>

Add flags to find libatomic in build-tree testing, fixing a catastrophic 
libgomp testsuite failure with targets such as `riscv-linux-gnu' that 
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 said 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.
---
Hi Jakub,

 Thank you for your review.

On Mon, 18 Nov 2019, Jakub Jelinek wrote:

> > --- gcc.orig/libgomp/testsuite/lib/libgomp.exp
> > +++ gcc/libgomp/testsuite/lib/libgomp.exp
> > @@ -174,6 +174,16 @@ 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 != "" } {
> > +	# Offload options imply `-pthread', and that implies `-latomic'
> > +	# on some targets, so wire in libatomic build directories.
> 
> -fopenmp is not an option I'd like to call Offload option, OpenMP is 
> much more than just offloading, and this isn't on some targets, but only 
> one, riscv*.
> So, I think it should be done only for that target and talk about 
> -fopenmp/-fopenacc options instead of Offload options.

 Thanks for straightening me out on OpenMP; I have adjusted the comment 
and the change description accordingly.

 I think it makes no sense to require people to update this test harness 
if a future target also requires access to libatomic; the `-L' option and 
the dynamic loader path are harmless if not required, as libatomic won't 
actually be pulled unless otherwise requested and there is no other 
library in libatomic's build directory that could be used unintentionally.  
Whereas in the absence of these settings a random version of libatomic 
already present somewhere on the system may accidentally be used and 
affect test results somehow.

 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 ?

  Maciej

Changes from v1:

- Replaced references to "offload options" with "`-fopenacc' and 
  `-fopenmp' options".
---
 libgomp/testsuite/lib/libgomp.exp |   11 +++++++++++
 1 file changed, 11 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,17 @@ 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 targets, so wire in libatomic
+	# build directories.
+	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 != "" } {

  reply	other threads:[~2019-11-19 23:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-09  1:15 [PATCH] " Maciej W. Rozycki
2019-11-18 13:08 ` [PING][PATCH] " Maciej W. Rozycki
2019-11-18 15:46 ` [PATCH] " Jakub Jelinek
2019-11-19 23:18   ` Maciej W. Rozycki [this message]
2019-11-19 23:29     ` [PATCH v2] " Jakub Jelinek
2019-11-20  2:27       ` [PATCH v3] " Maciej W. Rozycki
2019-11-20  8:25         ` Jakub Jelinek
2019-11-20 15:59           ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1911181735050.13542@redsun52.ssa.fujisawa.hgst.com \
    --to=macro@wdc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).