[PATCH 2/4] libffi/test: Fix compilation for build sysroot

[PATCH 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 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:

		=== libffi Summary ===

# of unexpected failures	708
# of unresolved testcases	708
# of unsupported tests		30

to:

		=== libffi Summary ===

# of expected passes		1934
# of unsupported tests		28

Also respect the TOOL_EXECUTABLE TCL variable for a standalone run via 
`runtest' and remove an unused TOOL_OPTIONS TCL variable instance.

	libffi/
	* configure.ac: Add testsuite/libffi-test-support.exp to output 
	files.
	* configure: Regenerate.
	* testsuite/libffi-test-support.exp.in: New file.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
	variable.
	* testsuite/Makefile.in: Regenerate.
	* testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST.
	(libffi_target_compile): Likewise.
---
 libffi/configure                            |    3 ++-
 libffi/configure.ac                         |    2 +-
 libffi/testsuite/Makefile.am                |    2 ++
 libffi/testsuite/Makefile.in                |    5 ++++-
 libffi/testsuite/lib/libffi.exp             |   16 ++++++++++++++--
 libffi/testsuite/libffi-test-support.exp.in |    1 +
 6 files changed, 24 insertions(+), 5 deletions(-)

gcc-test-libffi-gcc-under-test.diff
Index: gcc/libffi/configure
===================================================================
--- gcc.orig/libffi/configure
+++ gcc/libffi/configure
@@ -16635,7 +16635,7 @@ ac_config_commands="$ac_config_commands
 ac_config_links="$ac_config_links include/ffitarget.h:src/$TARGETDIR/ffitarget.h"
 
 
-ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc"
+ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile testsuite/Makefile testsuite/libffi-test-support.exp man/Makefile libffi.pc"
 
 
 cat >confcache <<\_ACEOF
@@ -17802,6 +17802,7 @@ do
     "include/ffi.h") CONFIG_FILES="$CONFIG_FILES include/ffi.h" ;;
     "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
     "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+    "testsuite/libffi-test-support.exp") CONFIG_FILES="$CONFIG_FILES testsuite/libffi-test-support.exp" ;;
     "man/Makefile") CONFIG_FILES="$CONFIG_FILES man/Makefile" ;;
     "libffi.pc") CONFIG_FILES="$CONFIG_FILES libffi.pc" ;;
 
Index: gcc/libffi/configure.ac
===================================================================
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -368,6 +368,6 @@ test -d src/$TARGETDIR || mkdir src/$TAR
 
 AC_CONFIG_LINKS(include/ffitarget.h:src/$TARGETDIR/ffitarget.h)
 
-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile testsuite/libffi-test-support.exp man/Makefile libffi.pc)
 
 AC_OUTPUT
Index: gcc/libffi/testsuite/Makefile.am
===================================================================
--- gcc.orig/libffi/testsuite/Makefile.am
+++ gcc/libffi/testsuite/Makefile.am
@@ -11,6 +11,8 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 	       echo $(top_srcdir)/../dejagnu/runtest ; \
 	    else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = libffi-test-support.exp
+
 AM_RUNTESTFLAGS =
 
 CLEANFILES = *.exe core* *.log *.sum
Index: gcc/libffi/testsuite/Makefile.in
===================================================================
--- gcc.orig/libffi/testsuite/Makefile.in
+++ gcc/libffi/testsuite/Makefile.in
@@ -105,7 +105,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/fficonfig.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libffi-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -278,6 +278,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 	       echo $(top_srcdir)/../dejagnu/runtest ; \
 	    else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = libffi-test-support.exp
 CLEANFILES = *.exe core* *.log *.sum
 EXTRA_DIST = config/default.exp libffi.call/cls_19byte.c		\
 libffi.call/cls_align_longdouble_split.c				\
@@ -389,6 +390,8 @@ $(top_srcdir)/configure: @MAINTAINER_MOD
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
 	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
+libffi-test-support.exp: $(top_builddir)/config.status $(srcdir)/libffi-test-support.exp.in
+	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
 	-rm -f *.lo
Index: gcc/libffi/testsuite/lib/libffi.exp
===================================================================
--- gcc.orig/libffi/testsuite/lib/libffi.exp
+++ gcc/libffi/testsuite/lib/libffi.exp
@@ -99,7 +99,8 @@ proc libffi-init { args } {
     global blddirffi
     global objdir
     global blddircxx
-    global TOOL_OPTIONS
+    global TOOL_EXECUTABLE
+    global GCC_UNDER_TEST
     global tool
     global libffi_include
     global libffi_link_flags
@@ -123,7 +124,15 @@ proc libffi-init { args } {
     set ld_library_path "."
     append ld_library_path ":${gccdir}"
 
-    set compiler "${gccdir}/xgcc"
+    if ![info exists GCC_UNDER_TEST] then {
+	if [info exists TOOL_EXECUTABLE] {
+	    set GCC_UNDER_TEST $TOOL_EXECUTABLE
+	} else {
+	    set GCC_UNDER_TEST "[find_gcc]"
+	}
+    }
+
+    set compiler [lindex $GCC_UNDER_TEST 0]
     if { [is_remote host] == 0 && [which $compiler] != 0 } {
 	foreach i "[exec $compiler --print-multi-lib]" {
 	    set mldir ""
@@ -175,11 +184,14 @@ proc libffi_target_compile { source dest
     global srcdir
     global blddirffi
     global TOOL_OPTIONS
+    global GCC_UNDER_TEST
     global libffi_link_flags
     global libffi_include
     global target_triplet
 
 
+    lappend options "compiler=$GCC_UNDER_TEST"
+
     if { [target_info needs_status_wrapper]!="" && [info exists gluefile] } {
 	lappend options "libs=${gluefile}"
 	lappend options "ldflags=$wrap_flags"
Index: gcc/libffi/testsuite/libffi-test-support.exp.in
===================================================================
--- /dev/null
+++ gcc/libffi/testsuite/libffi-test-support.exp.in
@@ -0,0 +1 @@
+set GCC_UNDER_TEST {@CC@}

[PATCH 1/4] libatomic/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libatomic testsuite using a method to determine 
the compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.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:

		=== libatomic Summary ===

# of unexpected failures	27
# of unresolved testcases	27

to:

		=== libatomic Summary ===

# of expected passes		54

	libatomic/
	* configure.ac: Add testsuite/libatomic-test-support.exp to 
	output files.
	* configure: Regenerate.
	* testsuite/libatomic-test-support.exp.in: New file.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
	variable.
	* testsuite/Makefile.in: Regenerate.
---
 libatomic/configure                               |    3 +++
 libatomic/configure.ac                            |    1 +
 libatomic/testsuite/Makefile.am                   |    2 ++
 libatomic/testsuite/Makefile.in                   |    5 ++++-
 libatomic/testsuite/libatomic-test-support.exp.in |    1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

gcc-test-libatomic-gcc-under-test.diff
Index: gcc/libatomic/configure
===================================================================
--- gcc.orig/libatomic/configure
+++ gcc/libatomic/configure
@@ -15701,6 +15701,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
+ac_config_files="$ac_config_files testsuite/libatomic-test-support.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -16772,6 +16774,7 @@ do
     "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
     "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
     "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+    "testsuite/libatomic-test-support.exp") CONFIG_FILES="$CONFIG_FILES testsuite/libatomic-test-support.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libatomic/configure.ac
===================================================================
--- gcc.orig/libatomic/configure.ac
+++ gcc/libatomic/configure.ac
@@ -279,4 +279,5 @@ else
 fi
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(testsuite/libatomic-test-support.exp)
 AC_OUTPUT
Index: gcc/libatomic/testsuite/Makefile.am
===================================================================
--- gcc.orig/libatomic/testsuite/Makefile.am
+++ gcc/libatomic/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_buildd
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-test-support.exp
Index: gcc/libatomic/testsuite/Makefile.in
===================================================================
--- gcc.orig/libatomic/testsuite/Makefile.in
+++ gcc/libatomic/testsuite/Makefile.in
@@ -108,7 +108,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/auto-config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libatomic-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -277,6 +277,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-test-support.exp
 all: all-am
 
 .SUFFIXES:
@@ -309,6 +310,8 @@ $(top_srcdir)/configure: @MAINTAINER_MOD
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
 	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
+libatomic-test-support.exp: $(top_builddir)/config.status $(srcdir)/libatomic-test-support.exp.in
+	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
 	-rm -f *.lo
Index: gcc/libatomic/testsuite/libatomic-test-support.exp.in
===================================================================
--- /dev/null
+++ gcc/libatomic/testsuite/libatomic-test-support.exp.in
@@ -0,0 +1 @@
+set GCC_UNDER_TEST {@CC@}

[PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

Hi,

 This patch series addresses a problem with the testsuite compiler being 
set up across libatomic, libffi, libgo, libgomp with no correlation 
whatsoever to the target compiler being used in GCC compilation.  
Consequently there in no arrangement made to set up the compilation 
sysroot according to the build sysroot specified for GCC compilation, 
causing a catastrophic failure across the testsuites affected from the 
inability to link executables.

 The fix is based on a similar arrangement already made for passing 
autoconf output variables in libgomp, and uses the GCC_UNDER_TEST (or 
GOC_UNDER_TEST, as applicable) TCL variable already used across several 
GCC library testsuites.

 Verified with a cross-compiler configured for the `riscv-linux-gnu' 
target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the 
user emulation mode as the target board.  Also no change in results with 
`x86_64-linux-gnu' native regression testing.

 See individual change descriptions for details.

 OK to apply to the GCC repo (for libraries maintained externally I'll be 
happy to assist with any merging required, although given that these 
changes are confined to autoconf/automake scriptery they should be 
straightforward to apply, barring any conflicts in generated files)?

  Maciej

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ulderico Cirello]

Hi Maciej,


Go's project doesn't take mail patches for changes. Please use gerrit (
https://go-review.googlesource.com/ ).


Thanks





        - ccf


On Mon, Nov 11, 2019 at 10:12 AM Maciej W. Rozycki <macro@wdc.com> wrote:

> Hi,
>
>  This patch series addresses a problem with the testsuite compiler being
> set up across libatomic, libffi, libgo, libgomp with no correlation
> whatsoever to the target compiler being used in GCC compilation.
> Consequently there in no arrangement made to set up the compilation
> sysroot according to the build sysroot specified for GCC compilation,
> causing a catastrophic failure across the testsuites affected from the
> inability to link executables.
>
>  The fix is based on a similar arrangement already made for passing
> autoconf output variables in libgomp, and uses the GCC_UNDER_TEST (or
> GOC_UNDER_TEST, as applicable) TCL variable already used across several
> GCC library testsuites.
>
>  Verified with a cross-compiler configured for the `riscv-linux-gnu'
> target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the
> user emulation mode as the target board.  Also no change in results with
> `x86_64-linux-gnu' native regression testing.
>
>  See individual change descriptions for details.
>
>  OK to apply to the GCC repo (for libraries maintained externally I'll be
> happy to assist with any merging required, although given that these
> changes are confined to autoconf/automake scriptery they should be
> straightforward to apply, barring any conflicts in generated files)?
>
>   Maciej
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/alpine.LFD.2.21.1911081714120.13542%40redsun52.ssa.fujisawa.hgst.com
> .
>

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Kaz Kylheku (libffi)]

On 2019-11-11 10:15, Ulderico Cirello wrote:
> Hi Maciej,
> 
> Go's project doesn't take mail patches for changes.

Is it that they'd have to read man pages and learn how to use common 
utilities?

Or that nobody has written a "patch in Go" yet?

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:15 AM Ulderico Cirello
<uldericofilho@gmail.com> wrote:
>
> Go's project doesn't take mail patches for changes. Please use gerrit ( https://go-review.googlesource.com/ ).

These patches are for gccgo, not the gc toolchain.  They should
probably have been sent to gofrontend-dev rather than golang-dev.  The
gccgo repo does take patches via e-mail; I route them through Gerrit
as needed.

Ian

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:31 AM Kaz Kylheku (libffi)
<382-725-6798@kylheku.com> wrote:
>
> On 2019-11-11 10:15, Ulderico Cirello wrote:
> > Hi Maciej,
> >
> > Go's project doesn't take mail patches for changes.
>
> Is it that they'd have to read man pages and learn how to use common
> utilities?
>
> Or that nobody has written a "patch in Go" yet?

Please be polite; thanks.  There are many advantages to using Gerrit
for code review.  It has nothing to do with reading man pages or using
the patch program.

Ian

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Ulderico Cirello wrote:

> Go's project doesn't take mail patches for changes. Please use gerrit (
> https://go-review.googlesource.com/ ).

 Thanks for your reply; this is however too much effort for my limited 
resources and a one-off change.

 The reason is I'm not actively working on Go and I have only enabled Go 
frontend compilation/verification for my RISC-V effort in case there is a 
regression caused by a machine backend change that happens to only trigger 
for the Go frontend so that it does not go unnoticed.

 I have provided this change in a hope it is useful to the community and 
in these circumstances hopefully someone actually interested in Go will 
pick up and merge this change; otherwise I will drop my local change and 
consequently Go verification once GCC 10 has been released.

 Thank you for your understanding.

  Maciej

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Ian Lance Taylor wrote:

> > Go's project doesn't take mail patches for changes. Please use gerrit ( https://go-review.googlesource.com/ ).
> 
> These patches are for gccgo, not the gc toolchain.  They should
> probably have been sent to gofrontend-dev rather than golang-dev.  The
> gccgo repo does take patches via e-mail; I route them through Gerrit
> as needed.

 I may have misinterpreted this paragraph[1]:

"Submitting Changes

   Changes to the Go frontend should follow the same process as for the
   main Go repository, only for the gofrontend project and the
   gofrontend-dev@googlegroups.com mailing list rather than the go project
   and the golang-dev@googlegroups.com mailing list. Those changes will
   then be merged into the GCC sources."

Sorry about that; I think it might benefit from a rewrite for clarity 
though.

References:

[1] "Contributing to the gccgo frontend - The Go Programming Language", 
    <https://golang.org/doc/gccgo_contribute.html>

  Maciej

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:44 AM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Mon, 11 Nov 2019, Ian Lance Taylor wrote:
>
> > > Go's project doesn't take mail patches for changes. Please use gerrit ( https://go-review.googlesource.com/ ).
> >
> > These patches are for gccgo, not the gc toolchain.  They should
> > probably have been sent to gofrontend-dev rather than golang-dev.  The
> > gccgo repo does take patches via e-mail; I route them through Gerrit
> > as needed.
>
>  I may have misinterpreted this paragraph[1]:
>
> "Submitting Changes
>
>    Changes to the Go frontend should follow the same process as for the
>    main Go repository, only for the gofrontend project and the
>    gofrontend-dev@googlegroups.com mailing list rather than the go project
>    and the golang-dev@googlegroups.com mailing list. Those changes will
>    then be merged into the GCC sources."
>
> Sorry about that; I think it might benefit from a rewrite for clarity
> though.
>
> References:
>
> [1] "Contributing to the gccgo frontend - The Go Programming Language",
>     <https://golang.org/doc/gccgo_contribute.html>


The paragraph seems reasonable clear to me, so I'm obviously missing
something.  Can you suggest a clearer rewrite?  Thanks.

Ian

[PING][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

  Maciej

[PING^2][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

  Maciej

[PING^3][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

  Maciej

[PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

  Maciej

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Mike Stump]

On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki <macro@wdc.com> wrote:
> 
> On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:
> 
>> This patch series addresses a problem with the testsuite compiler being 
>> set up across libatomic, libffi, libgo, libgomp with no correlation 
>> whatsoever to the target compiler being used in GCC compilation.  
>> Consequently there in no arrangement made to set up the compilation 
>> sysroot according to the build sysroot specified for GCC compilation, 
>> causing a catastrophic failure across the testsuites affected from the 
>> inability to link executables.
> 
> Ping for:
> 
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

Hum...  I'm wondering who should review this...  Feels like I should, the problem is it intertwines with the build system as well.   So, let me approve the testsuite parts so that can clear the way for someone else to approve the remaining bits (if not obvious).

Please do watch out for breakages as it goes in.  Thanks.

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Thanks for your review; I have applied 4/4 as it doesn't contain any 
non-testsuite parts and will continue pinging 1/4 and 2/4 for the build 
system bits then (3/4 has been already committed by the Go maintainer).

> Please do watch out for breakages as it goes in.  Thanks.

 Sure!

  Maciej

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Julian Brown]

Hi Maciej,

On Sun, 22 Dec 2019 00:43:54 +0000 (GMT)
"Maciej W. Rozycki" <macro@wdc.com> wrote:

> On Fri, 20 Dec 2019, Mike Stump wrote:
> 
> > >> This patch series addresses a problem with the testsuite
> > >> compiler being set up across libatomic, libffi, libgo, libgomp
> > >> with no correlation whatsoever to the target compiler being used
> > >> in GCC compilation. Consequently there in no arrangement made to
> > >> set up the compilation sysroot according to the build sysroot
> > >> specified for GCC compilation, causing a catastrophic failure
> > >> across the testsuites affected from the inability to link
> > >> executables.  
> > > 
> > > Ping for:
> > > 
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>  
> > 
> > Hum...  I'm wondering who should review this...  Feels like I
> > should, the problem is it intertwines with the build system as
> > well.  So, let me approve the testsuite parts so that can clear the
> > way for someone else to approve the remaining bits (if not
> > obvious).  
> 
>  Thanks for your review; I have applied 4/4 as it doesn't contain any 
> non-testsuite parts and will continue pinging 1/4 and 2/4 for the
> build system bits then (3/4 has been already committed by the Go
> maintainer).
> 
> > Please do watch out for breakages as it goes in.  Thanks.  
> 
>  Sure!

FYI: This patch seems to be causing problems for our (internal -- as
you know!) test harness. I'm not sure if it's a local issue (or at least
something we can work around here), or a problem with the patch itself
though.

I'm currently working on offloading-enabled compilers. I see the same
failure mode for both AMD GCN and NVPTX.

Without the patch, the compiler is found (with [find_gcc] I suppose) and
invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
(I think) "installed testing", which IIUC is atypical.

With the patch, the compiler is invoked as (at the risk of excessive
detail) e.g.:

/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/xgcc -B/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/lib/ -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/include -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/sys-include --sysroot=/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc [...]

...and then it fails to find libgomp.spec:

xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or directory

Can your approach be made to work with an offload-enabled compiler? How
should that spec file (and/or the target compiler) be located?

Thanks,

Julian

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

Hi Julian,

> FYI: This patch seems to be causing problems for our (internal -- as
> you know!) test harness. I'm not sure if it's a local issue (or at least
> something we can work around here), or a problem with the patch itself
> though.

 I'm sorry to break your setup.  I'm currently a little bit busy before a 
conference next week I speak at, however I'll try to address your problem 
the best I can regardless.

> I'm currently working on offloading-enabled compilers. I see the same
> failure mode for both AMD GCN and NVPTX.
> 
> Without the patch, the compiler is found (with [find_gcc] I suppose) and
> invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
> (I think) "installed testing", which IIUC is atypical.

 I'm not sure if the libgomp-test-support.exp file produced by the build 
is supposed to be used in standalone testing rather than one that has been 
separately prepared for the standalone environment in question.

 However before I make any definite conclusion I would like to understand 
how things are supposed to work with an offload-enabled compiler.

> With the patch, the compiler is invoked as (at the risk of excessive
> detail) e.g.:
> 
> /scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/xgcc -B/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-999999-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin/ -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/lib/ -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/include -isystem /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/sys-include --sysroot=/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc [...]
> 
> ...and then it fails to find libgomp.spec:
> 
> xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or directory
> 
> Can your approach be made to work with an offload-enabled compiler? How
> should that spec file (and/or the target compiler) be located?

 As I recall there is a separate compiler invoked for the offload target.  
I don't have a suitable setup available to hand nor an easy way to make 
one.  Can you therefore please figure out and tell me how this is 
arranged?  Also where does the libgomp.spec file come from?

 Overall if libgomp-test-support.exp is considered appropriate for 
standalone testing, then I think two solutions are possible here:

1. An option is added to libgomp's $CC such that the compiler is able to 
   make builds involving the offload compiler where requested, and this 
   then propagates to GCC_UNDER_TEST as it stands.

2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only 
   made if inexistent, and then you can predefine the variable in site.exp 
   however you find appropriate.

  Maciej

[PING^5][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Ping for the build system parts of:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>

  Maciej

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Tobias Burnus]

Hi Maciej,

On 1/6/20 4:25 PM, Maciej W. Rozycki wrote:
>> Without the patch, the compiler is found (with [find_gcc] I suppose) and
>> invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
>> (I think) "installed testing", which IIUC is atypical.
[…]
> However before I make any definite conclusion I would like to understand
> how things are supposed to work with an offload-enabled compiler.
> […]
> As I recall there is a separate compiler invoked for the offload target.
> I don't have a suitable setup available to handnor an easy way to make
> one.  Can you therefore please figure out and tell me how this is
> arranged?  Also where does the libgomp.spec file come from?

The main compiler, targetting the host, splits off the device functions 
– and those are processed via lto-wrapper (for each device target) – and 
then at the end, the host and device parts are combined, cf. 
https://gcc.gnu.org/wiki/Offloading – search for "mkoffload".

In terms of directory structure, one has something like:

./libexec/gcc/x86_64-none-linux-gnu/10.0.0/lto1
./libexec/gcc/x86_64-none-linux-gnu/10.0.0/accel/nvptx-none/lto1
./libexec/gcc/x86_64-none-linux-gnu/10.0.0/accel/nvptx-none/mkoffload
./nvptx-none/lib/libgomp.spec
./x86_64-none-linux-gnu/lib64/libgomp.spec

And the compiler is configured to know which accelerators are available 
because it has been configured such. See for instance 
https://sources.debian.org/src/gcc-10/10-20200107-1/debian/rules2/ for 
how building an offload compiler (nvptx + [new with GCC 10:] gcn) works.

> 2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only
>     made if inexistent, and then you can predefine the variable in site.exp
>     however you find appropriate.

I think that's sounds like a reasonable approach. However, I believe 
others (including you) know much more about sysroot etc. than I do. (I 
either do in-build-tree testing (w/o offloading, w/o sysroot) on 
x86-linux or simply run a run-testsuite script as a black box.)

Tobias

[PING^6][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Ping for the build system parts of:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>

  Maciej

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Chung-Lin Tang]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On 2020/1/6 11:25 PM, Maciej W. Rozycki wrote:
>   Overall if libgomp-test-support.exp is considered appropriate for
> standalone testing, then I think two solutions are possible here:
> 
> 1. An option is added to libgomp's $CC such that the compiler is able to
>     make builds involving the offload compiler where requested, and this
>     then propagates to GCC_UNDER_TEST as it stands.
> 
> 2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only
>     made if inexistent, and then you can predefine the variable in site.exp
>     however you find appropriate.

Hi Maciej,
I understand your situation with --with-build-sysroot/--without-sysroot, but the
way you set GCC_UNDER_TEST in libgomp-test-support.exp appears to override too
much of the machinery in libgomp/testsuite/lib/libgomp.exp that sets GCC_UNDER_TEST
using DejaGNU find_gcc, etc.

Can you test if the attached patch works for you? The patch exports the build sysroot
setting from the toplevel to target library subdirs, and adds the --sysroot= option
when doing build-tree testing (I assume that blddir != "" test is sufficient from the
surrounding comments)

I can only verify that it no longer "interferes" with our installed-mode testing.
Also, if this does work, then other library testsuites (e.g. libatomic.exp) might
also need considering updating, I think.

Thanks,
Chung-Lin

2020-01-14  Chung-Lin Tang  <cltang@codesourcery.com>

	* Makefile.tpl	(NORMAL_TARGET_EXPORTS): Add export of
	SYSROOT_CFLAGS_FOR_TARGET variable.
	* Makefile.in:	Regenerate.

	libgomp/
	* testsuite/lib/libgomp.exp (ALWAYS_CFLAGS): Add
	--sysroot=$SYSROOT_CFLAGS_FOR_TARGET option when doing build-tree testing.
	Fix comment typo.
	* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Delete definition.

[-- Attachment #2: m.diff --]
[-- Type: text/plain, Size: 2393 bytes --]

Index: libgomp/testsuite/lib/libgomp.exp
===================================================================
--- libgomp/testsuite/lib/libgomp.exp	(revision 279954)
+++ libgomp/testsuite/lib/libgomp.exp	(working copy)
@@ -171,9 +171,16 @@ proc libgomp_init { args } {
     lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
     lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
 
-    # For build-tree testing, also consider the library paths used for builing.
+    # For build-tree testing, also consider the library paths used for building.
     # For installed testing, we assume all that to be provided in the sysroot.
     if { $blddir != "" } {
+
+	# If --with-build-sysroot= was specified, we assume it will be needed
+	# for build-tree testing.
+	if [info exists SYSROOT_CFLAGS_FOR_TARGET] {
+	    lappend ALWAYS_CFLAGS "additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
+	}
+	
 	# The `-fopenacc' and `-fopenmp' options imply `-pthread', and
 	# that implies `-latomic' on some hosts, so wire in libatomic
 	# build directories.
Index: libgomp/testsuite/libgomp-test-support.exp.in
===================================================================
--- libgomp/testsuite/libgomp-test-support.exp.in	(revision 279954)
+++ libgomp/testsuite/libgomp-test-support.exp.in	(working copy)
@@ -1,5 +1,3 @@
-set GCC_UNDER_TEST {@CC@}
-
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
 set hsa_runtime_lib "@HSA_RUNTIME_LIB@"
Index: Makefile.in
===================================================================
--- Makefile.in	(revision 279954)
+++ Makefile.in	(working copy)
@@ -319,6 +319,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
 	$(BASE_TARGET_EXPORTS) \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 279954)
+++ Makefile.tpl	(working copy)
@@ -322,6 +322,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
 	$(BASE_TARGET_EXPORTS) \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP

[PING^7][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Ping for the build system parts of:

<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>

  Maciej

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Tue, 14 Jan 2020, Chung-Lin Tang wrote:

> Can you test if the attached patch works for you? The patch exports the build sysroot
> setting from the toplevel to target library subdirs, and adds the --sysroot= option
> when doing build-tree testing (I assume that blddir != "" test is sufficient from the
> surrounding comments)

 Thank you for your proposal; however I'm a little concerned as to 
continuing using the current compiler detect logic for testing uninstalled 
GCC as it may incorrectly pick a compiler already present on the system 
rather than the newly built one.  I think the way it's done in gcc/ by 
using the configured $CC, etc. is the correct one and we should strive to 
replicate it across top-level libraries as well.

 I'll give your proposal a shot and I'm lucky enough to have a build 
configuration where I can have no compiler preinstalled, so at least I can 
check if testing with your change applied correctly picks the newly built 
uninstalled compiler in that case.

  Maciej

Re: [PING^7][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Jeff Law]

On Tue, 2020-01-21 at 02:19 +0000, Maciej W. Rozycki wrote:
> On Fri, 20 Dec 2019, Mike Stump wrote:
> 
> > > > This patch series addresses a problem with the testsuite compiler being 
> > > > set up across libatomic, libffi, libgo, libgomp with no correlation 
> > > > whatsoever to the target compiler being used in GCC compilation.  
> > > > Consequently there in no arrangement made to set up the compilation 
> > > > sysroot according to the build sysroot specified for GCC compilation, 
> > > > causing a catastrophic failure across the testsuites affected from the 
> > > > inability to link executables.
> > > 
> > > Ping for:
> > > 
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> > > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> > 
> > Hum...  I'm wondering who should review this...  Feels like I should, 
> > the problem is it intertwines with the build system as well.  So, let me 
> > approve the testsuite parts so that can clear the way for someone else 
> > to approve the remaining bits (if not obvious).
> 
>  Ping for the build system parts of:
> 
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
OK.  Sorry for the terrible slowness on this kit.
jeff

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Tue, 21 Jan 2020, Maciej W. Rozycki wrote:

>  I'll give your proposal a shot and I'm lucky enough to have a build 
> configuration where I can have no compiler preinstalled, so at least I can 
> check if testing with your change applied correctly picks the newly built 
> uninstalled compiler in that case.

 So it does seem to pick the right uninstalled compiler, however without 
the sysroot option and therefore all tests fail either like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libgomp.c/../libgomp.c-c++-common/depend-iterator-2.c (test for excess errors)

or like:

.../libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/cancel-parallel-1.c:4:10: fatal error: stdlib.h: No such file or directory
compilation terminated.
compiler exited with status 1
FAIL: libgomp.c/../libgomp.c-c++-common/cancel-parallel-1.c (test for excess errors)

I am somewhat wary about picking the compiler options to pass selectively 
anyway.  However the change below does not do that and works for me and I 
think it should be fine for your use case too.  Please confirm.

 I'm yet verifying the other libraries with corresponding changes and will 
formally submit v2 of this series once that has completed.

 Apologies for the slightly long RTT with this update.

  Maciej

---
 libgomp/testsuite/Makefile.am                 |    1 +
 libgomp/testsuite/Makefile.in                 |    1 +
 libgomp/testsuite/libgomp-test-support.exp.in |    2 --
 3 files changed, 2 insertions(+), 2 deletions(-)

gcc-test-libgomp-runtestflags-tool-exec.diff
Index: gcc/libgomp/testsuite/Makefile.am
===================================================================
--- gcc.orig/libgomp/testsuite/Makefile.am
+++ gcc/libgomp/testsuite/Makefile.am
@@ -11,6 +11,7 @@ EXPECT = $(shell if test -f $(top_buildd
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
 
 # Instead of directly in ../testsuite/libgomp-test-support.exp.in, the
 # following variables have to be "routed through" this Makefile, for expansion
Index: gcc/libgomp/testsuite/Makefile.in
===================================================================
--- gcc.orig/libgomp/testsuite/Makefile.in
+++ gcc/libgomp/testsuite/Makefile.in
@@ -308,6 +308,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
 all: all-am
 
 .SUFFIXES:
Index: gcc/libgomp/testsuite/libgomp-test-support.exp.in
===================================================================
--- gcc.orig/libgomp/testsuite/libgomp-test-support.exp.in
+++ gcc/libgomp/testsuite/libgomp-test-support.exp.in
@@ -1,5 +1,3 @@
-set GCC_UNDER_TEST {@CC@}
-
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
 set hsa_runtime_lib "@HSA_RUNTIME_LIB@"

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Chung-Lin Tang]

Hi Maciej,
sorry for the late reply.

On 2020/2/1 5:46 AM, Maciej W. Rozycki wrote:
> On Tue, 21 Jan 2020, Maciej W. Rozycki wrote:
> 
>>   I'll give your proposal a shot and I'm lucky enough to have a build
>> configuration where I can have no compiler preinstalled, so at least I can
>> check if testing with your change applied correctly picks the newly built
>> uninstalled compiler in that case.
> 
>   So it does seem to pick the right uninstalled compiler, however without
> the sysroot option and therefore all tests fail either like:
> 
> .../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
> .../bin/riscv64-linux-gnu-ld: cannot find -lm
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: libgomp.c/../libgomp.c-c++-common/depend-iterator-2.c (test for excess errors)
> 
> or like:
> 
> .../libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/cancel-parallel-1.c:4:10: fatal error: stdlib.h: No such file or directory
> compilation terminated.
> compiler exited with status 1
> FAIL: libgomp.c/../libgomp.c-c++-common/cancel-parallel-1.c (test for excess errors)

Weird that the --sysroot option doesn't properly get down there. I'll try to whip up a
similar environment later to really test this myself if I have time. As for your patch...

> I am somewhat wary about picking the compiler options to pass selectively
> anyway.  However the change below does not do that and works for me and I
> think it should be fine for your use case too.  Please confirm.
> 
>   I'm yet verifying the other libraries with corresponding changes and will
> formally submit v2 of this series once that has completed.
> 
>   Apologies for the slightly long RTT with this update.
> 
>    Maciej

The 'AM_RUNTESTFLAGS = --tool_exec "$(CC)"' does work for us, but only because you backed out the change
from libgomp-test-support.exp, and our installed testing doesn't use the libgomp/testsuite/Makefile.* files
(we invoke runtest using another script).

 From the code in libgomp/testsuite/lib/libgomp.exp:libgomp_init():
...
     if ![info exists GCC_UNDER_TEST] then {
         if [info exists TOOL_EXECUTABLE] {
             set GCC_UNDER_TEST $TOOL_EXECUTABLE
         } else {
             set GCC_UNDER_TEST "[find_gcc]"
         }
     }

So essentially this patch is the same as the prior one, and still blocks the usual find_gcc logic from
ever getting control (as long as we use the in-tree 'make check'). I'm not sure that is the right
thing to do...

That said, I don't have anything further against this patch. Okay for me.

(I do still think that actually detecting the right in-tree compiler and giving the correct sysroot
options from the configuration is the more proper approach, maybe later)

Thanks,
Chung-Lin

> ---
>   libgomp/testsuite/Makefile.am                 |    1 +
>   libgomp/testsuite/Makefile.in                 |    1 +
>   libgomp/testsuite/libgomp-test-support.exp.in |    2 --
>   3 files changed, 2 insertions(+), 2 deletions(-)
> 
> gcc-test-libgomp-runtestflags-tool-exec.diff
> Index: gcc/libgomp/testsuite/Makefile.am
> ===================================================================
> --- gcc.orig/libgomp/testsuite/Makefile.am
> +++ gcc/libgomp/testsuite/Makefile.am
> @@ -11,6 +11,7 @@ EXPECT = $(shell if test -f $(top_buildd
>   _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
>   	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
>   RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
> +AM_RUNTESTFLAGS = --tool_exec "$(CC)"
>   
>   # Instead of directly in ../testsuite/libgomp-test-support.exp.in, the
>   # following variables have to be "routed through" this Makefile, for expansion
> Index: gcc/libgomp/testsuite/Makefile.in
> ===================================================================
> --- gcc.orig/libgomp/testsuite/Makefile.in
> +++ gcc/libgomp/testsuite/Makefile.in
> @@ -308,6 +308,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
>   	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
>   
>   RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
> +AM_RUNTESTFLAGS = --tool_exec "$(CC)"
>   all: all-am
>   
>   .SUFFIXES:
> Index: gcc/libgomp/testsuite/libgomp-test-support.exp.in
> ===================================================================
> --- gcc.orig/libgomp/testsuite/libgomp-test-support.exp.in
> +++ gcc/libgomp/testsuite/libgomp-test-support.exp.in
> @@ -1,5 +1,3 @@
> -set GCC_UNDER_TEST {@CC@}
> -
>   set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
>   set cuda_driver_lib "@CUDA_DRIVER_LIB@"
>   set hsa_runtime_lib "@HSA_RUNTIME_LIB@"
> 

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

Hi Chung-Lin,

> sorry for the late reply.

 No worries.

> The 'AM_RUNTESTFLAGS = --tool_exec "$(CC)"' does work for us, but only because you backed out the change
> from libgomp-test-support.exp, and our installed testing doesn't use the libgomp/testsuite/Makefile.* files
> (we invoke runtest using another script).
> 
>  From the code in libgomp/testsuite/lib/libgomp.exp:libgomp_init():
> ...
>      if ![info exists GCC_UNDER_TEST] then {
>          if [info exists TOOL_EXECUTABLE] {
>              set GCC_UNDER_TEST $TOOL_EXECUTABLE
>          } else {
>              set GCC_UNDER_TEST "[find_gcc]"
>          }
>      }
> 
> So essentially this patch is the same as the prior one, and still blocks the usual find_gcc logic from
> ever getting control (as long as we use the in-tree 'make check'). I'm not sure that is the right
> thing to do...

 That is intentional.  The libgomp.exp test driver is generic and can be 
invoked standalone (e.g. with `contrib/test_installed'), in which case the 
user will decide with `runtest' options whether to use a compiler pointed 
at explicitly or to fall back to `[find_gcc]'.

 OTOH `make check' is tied to the build tree and I think it ought to use 
the same compiler, there's no point in using any compiler search logic.

 The only uncertainty was about libgomp-test-support.exp.  Since it's 
generated I concluded it could be treated as tied to the build tree, 
however your use case has served as a counter example, so I have backed 
out my change as I have come up with a change that is equally good for my 
purpose and does not cause you and possibly other people trouble.

> That said, I don't have anything further against this patch. Okay for me.

 Great, thanks for verifying my proposal.

> (I do still think that actually detecting the right in-tree compiler and giving the correct sysroot
> options from the configuration is the more proper approach, maybe later)

 Well, the in-tree compiler is $(CC), $(CXX), etc., as embedded in the 
Makefile structure, and I don't think you can guess it in DejaGNU without 
referring to those `make' variables.

 I'll post an updated series; it has passed my testing.

  Maciej

Re: [PING^7][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Sun, 26 Jan 2020, Jeff Law wrote:

> >  Ping for the build system parts of:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00767.html>
> > <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00768.html>
> OK.  Sorry for the terrible slowness on this kit.

 No worries, completely understood with all the attention required by the 
switch to Git.

 Thank you for your review.  However Julian and Chung-Lin reported issues 
with the libgomp part previously committed and I have concluded all the 
changes have to be completely rewritten.  I have posted v2 now.

  Maciej

Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 7043 bytes --]

Hi!

For context:

In early 2020, Maciej pushed a set of changes that made target libraries
capture their build-time 'CC' for test-time usage as 'GCC_UNDER_TEST'
(via the respective 'site.exp'), for build-tree testing (but not
installed testing).  This was motivated by the need for '--sysroot=[...]'
as set per '--with-build-sysroot=[...]'.  For example, for libgomp that's
Subversion r279708 (Git commit c8e759b4215ba4b376c9d468aeffe163b3d520f0)
"libgomp/test: Fix compilation for build sysroot", followed by
Git commit 749bd22ddc50b5112e5ed506ffef7249bf8e6fb3
"libgomp/test: Remove a build sysroot fix regression".  (Similarly other
commits for a number of (but not all?) other target libraries).

In recent Git commit 11f4d483600b5788a3d1cf1527e838e4a7ed1455
"libgomp testsuite: As appropriate, use the 'gcc', 'g++', 'gfortran' driver [PR91884]"
I've then extended this approach for 'CXX': 'GXX_UNDER_TEST',
'FC': 'GFORTRAN_UNDER_TEST'.

Per <https://gcc.gnu.org/PR109951>
"libgomp, testsuite: non-native multilib c++ tests fail on Darwin"
we have however found that there is a conceptual problem in the original
approach: the build-time 'CC' etc. potentially are different per multilib
build of the target library (say, multilib-specific '-L[...]'  flags),
whereas the test-time usage will always use the 'GCC_UNDER_TEST', thus
build-time 'CC' of the default multilib.  (This is fundamental in how the
GCC/DejaGnu testsuite is set up; we're not going to change this without
considerable effort.)  Often this is not a problem (if, effectively,
non-applicable flags etc. are dropped silently, for example), but as Iain
has demonstrated, this is an actual problem in certain configurations
(if, effectively, non-applicable flags etc. cause diagnostics, for
example).

Now, back then, Chung-Lin actually had a different proposal:

On 2020-01-14T21:31:13+0800, Chung-Lin Tang <chunglin_tang@mentor.com> wrote:
> I understand your situation with --with-build-sysroot/--without-sysroot, [...]
>
> Can you test if the attached patch works for you? The patch exports the build sysroot
> setting from the toplevel to target library subdirs, and adds the --sysroot= option
> when doing build-tree testing [...]

Belatedly: thanks, I like that approach better indeed.

This is, by the way, in line with what GCC compiler testing is doing;
'gcc/Makefile.in':

    # Set if the compiler was configured with --with-build-sysroot.
    SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@

    # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation.
    # They are passed first to allow individual tests to override them.
            @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp

That is, via 'site.exp', put 'SYSROOT_CFLAGS_FOR_TARGET' into
'TEST_ALWAYS_FLAGS', which is "passed to every compilation".

> [...], if this does work, then other library testsuites (e.g. libatomic.exp) might
> also need considering updating, I think.

Correct.  (I'm offering to take care of that.)

> 2020-01-14  Chung-Lin Tang  <cltang@codesourcery.com>
>
>       * Makefile.tpl  (NORMAL_TARGET_EXPORTS): Add export of
>       SYSROOT_CFLAGS_FOR_TARGET variable.
>       * Makefile.in:  Regenerate.
>
>       libgomp/
>       * testsuite/lib/libgomp.exp (ALWAYS_CFLAGS): Add
>       --sysroot=$SYSROOT_CFLAGS_FOR_TARGET option when doing build-tree testing.
>       Fix comment typo.
>       * testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Delete definition.

To that, Maciej had to report:

On 2020-01-31T21:46:01+0000, "Maciej W. Rozycki" <macro@wdc.com> wrote:
>  So it does seem to pick the right uninstalled compiler, however without
> the sysroot option and therefore all tests fail [...]

That, however, is not a conceptual but simply an implementation problem:

> --- libgomp/testsuite/lib/libgomp.exp (revision 279954)
> +++ libgomp/testsuite/lib/libgomp.exp (working copy)
> @@ -171,9 +171,16 @@ proc libgomp_init { args } {
>      lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
>      lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
>
> -    # For build-tree testing, also consider the library paths used for builing.
> +    # For build-tree testing, also consider the library paths used for building.
>      # For installed testing, we assume all that to be provided in the sysroot.
>      if { $blddir != "" } {
> +
> +     # If --with-build-sysroot= was specified, we assume it will be needed
> +     # for build-tree testing.
> +     if [info exists SYSROOT_CFLAGS_FOR_TARGET] {
> +         lappend ALWAYS_CFLAGS "additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
> +     }

Need 'global SYSROOT_CFLAGS_FOR_TARGET'.

Need to change:

    -       lappend ALWAYS_CFLAGS "additional_flags=--sysroot=$SYSROOT_CFLAGS_FOR_TARGET"
    +       lappend ALWAYS_CFLAGS "additional_flags=$SYSROOT_CFLAGS_FOR_TARGET"

..., as 'SYSROOT_CFLAGS_FOR_TARGET' already includes '--sysroot=' prefix.

> --- libgomp/testsuite/libgomp-test-support.exp.in     (revision 279954)
> +++ libgomp/testsuite/libgomp-test-support.exp.in     (working copy)
> @@ -1,5 +1,3 @@
> -set GCC_UNDER_TEST {@CC@}

Also need to capture 'SYSROOT_CFLAGS_FOR_TARGET' here, so that it's then
available at test time.

> --- Makefile.tpl      (revision 279954)
> +++ Makefile.tpl      (working copy)
> @@ -322,6 +322,7 @@ RAW_CXX_TARGET_EXPORTS = \
>
>  NORMAL_TARGET_EXPORTS = \
>       $(BASE_TARGET_EXPORTS) \
> +     SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
>       CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;

With that one moved into the generic 'BASE_TARGET_EXPORTS', adapting
things to the current state of affaris plus some polishing, the attached
"Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]"
appears to be doing the right thing per my (limited, so far) testing.

Will you, Maciej, please test that this doesn't break your setting?

Will you, Iain, please test that this does address
<https://gcc.gnu.org/PR109951>
"libgomp, testsuite: non-native multilib c++ tests fail on Darwin"?

Anybody got any other comments?

Once that's all clear, we may either push this one already, and then I
work on applying the same changes to other target libraries
incrementally, or do all that at once.  I suppose: "push this one
already", to restore Iain's testing as well as giving these changes some
wider exposure, and in parallel "I work on applying the same changes to
other target libraries incrementally"?


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Consider-with-build-sysroot-.-for-target-libraries-b.patch --]
[-- Type: text/x-diff, Size: 10545 bytes --]

From ab5d1d3ef91b2ad7e1ed262c9487f727b79ceb3f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu, 1 Jun 2023 23:07:37 +0200
Subject: [PATCH] Consider '--with-build-sysroot=[...]' for target libraries'
 build-tree testing (instead of build-time 'CC' etc.) [PR109951]

	PR testsuite/109951
	* Makefile.tpl (BASE_TARGET_EXPORTS): Add
	'SYSROOT_CFLAGS_FOR_TARGET'.
	* Makefile.in: Regenerate.
	libgomp/
	* configure.ac: Revert earlier changes, instead
	'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
	* testsuite/lib/libgomp.exp (libgomp_init): Remove
	"Fix up '-funconfigured-libstdc++-v3' in 'GXX_UNDER_TEST'" code.
	If '--with-build-sysroot=[...]' was specified, use it for
	build-tree testing.
	* testsuite/libgomp-site-extra.exp.in (GCC_UNDER_TEST)
	(GXX_UNDER_TEST, GFORTRAN_UNDER_TEST): Don't set.
	(SYSROOT_CFLAGS_FOR_TARGET): Set.
	* testsuite/libgomp.c++/c++.exp (lang_source_re)
	(lang_include_flags): Set for build-tree testing.
	* testsuite/libgomp.oacc-c++/c++.exp (lang_source_re)
	(lang_include_flags): Likewise.

Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
---
 Makefile.in                                 |  1 +
 Makefile.tpl                                |  1 +
 libgomp/Makefile.in                         |  2 +-
 libgomp/configure                           | 17 ++++-------------
 libgomp/configure.ac                        | 15 +++------------
 libgomp/testsuite/Makefile.in               |  2 +-
 libgomp/testsuite/lib/libgomp.exp           | 18 +++++-------------
 libgomp/testsuite/libgomp-site-extra.exp.in |  4 +---
 libgomp/testsuite/libgomp.c++/c++.exp       |  6 ++++++
 libgomp/testsuite/libgomp.oacc-c++/c++.exp  |  6 ++++++
 10 files changed, 29 insertions(+), 43 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index b559454cc90..e75bd98bde5 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -320,6 +320,7 @@ BASE_TARGET_EXPORTS = \
 	RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
 	READELF="$(READELF_FOR_TARGET)"; export READELF; \
 	STRIP="$(STRIP_FOR_TARGET)"; export STRIP; \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
 	WINDMC="$(WINDMC_FOR_TARGET)"; export WINDMC; \
 @if gcc-bootstrap
diff --git a/Makefile.tpl b/Makefile.tpl
index 6bcee3021c9..91bb9d279e4 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -323,6 +323,7 @@ BASE_TARGET_EXPORTS = \
 	RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
 	READELF="$(READELF_FOR_TARGET)"; export READELF; \
 	STRIP="$(STRIP_FOR_TARGET)"; export STRIP; \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
 	WINDMC="$(WINDMC_FOR_TARGET)"; export WINDMC; \
 @if gcc-bootstrap
diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 3ef05e6a3cb..431bc87b629 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -368,7 +368,6 @@ CFLAGS = @CFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
 CPU_COUNT = @CPU_COUNT@
-CXX = @CXX@
 CYGPATH_W = @CYGPATH_W@
 DEFS = @DEFS@
 DEPDIR = @DEPDIR@
@@ -436,6 +435,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
 XLDFLAGS = @XLDFLAGS@
diff --git a/libgomp/configure b/libgomp/configure
index e4e79c5199a..26557ac44f7 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -656,6 +656,7 @@ tmake_file
 XLDFLAGS
 XCFLAGS
 config_path
+SYSROOT_CFLAGS_FOR_TARGET
 FLOCK
 CPU_COUNT
 LIBGOMP_BUILD_VERSIONED_SHLIB_SUN_FALSE
@@ -679,7 +680,6 @@ libtool_VERSION
 ac_ct_FC
 FCFLAGS
 FC
-CXX
 MAINT
 MAINTAINER_MODE_FALSE
 MAINTAINER_MODE_TRUE
@@ -11770,22 +11770,11 @@ fi
 
 
 
-# We optionally test libgomp C++ support, and for that want to use the proper
-# C++ driver, 'g++' (or 'xg++' for build-tree testing).  Given that build of
-# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we
-# cannot make build of target libgomp depend on target libstdc++-v3: circular
-# dependency.  We thus cannot instantiate 'AC_PROG_CXX' here: we'd get
-# '-funconfigured-libstdc++-v3' (see '../configure.ac').  Therefore, just
-# capture 'CXX', and we'll fix this up at 'make check' time (see
-# 'testsuite/lib/libgomp.exp:libgomp_init').
-
-
 # Create a spec file, so that compile/link tests don't fail
 test -f libgfortran.spec || touch libgfortran.spec
 FCFLAGS="$FCFLAGS -L."
 
-# We need 'gfortran' to compile parts of the library, and test libgomp Fortran
-# support.
+# We need gfortran to compile parts of the library
 # We can't use AC_PROG_FC because it expects a fully working gfortran.
 #AC_PROG_FC(gfortran)
 case `echo $GFORTRAN` in
@@ -16542,6 +16531,8 @@ fi
 
 fi
 
+
+
 # Get target configury.
 . ${srcdir}/configure.tgt
 CFLAGS="$save_CFLAGS $XCFLAGS"
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 1aad83a79da..49f7fb0dc82 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -151,22 +151,11 @@ AC_SUBST(enable_static)
 
 AM_MAINTAINER_MODE
 
-# We optionally test libgomp C++ support, and for that want to use the proper
-# C++ driver, 'g++' (or 'xg++' for build-tree testing).  Given that build of
-# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we
-# cannot make build of target libgomp depend on target libstdc++-v3: circular
-# dependency.  We thus cannot instantiate 'AC_PROG_CXX' here: we'd get
-# '-funconfigured-libstdc++-v3' (see '../configure.ac').  Therefore, just
-# capture 'CXX', and we'll fix this up at 'make check' time (see
-# 'testsuite/lib/libgomp.exp:libgomp_init').
-AC_SUBST(CXX)
-
 # Create a spec file, so that compile/link tests don't fail
 test -f libgfortran.spec || touch libgfortran.spec
 FCFLAGS="$FCFLAGS -L."
 
-# We need 'gfortran' to compile parts of the library, and test libgomp Fortran
-# support.
+# We need gfortran to compile parts of the library
 # We can't use AC_PROG_FC because it expects a fully working gfortran.
 #AC_PROG_FC(gfortran)
 case `echo $GFORTRAN` in
@@ -356,6 +345,8 @@ if test -z "$FLOCK"; then
   AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
 fi
 
+AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
+
 # Get target configury.
 . ${srcdir}/configure.tgt
 CFLAGS="$save_CFLAGS $XCFLAGS"
diff --git a/libgomp/testsuite/Makefile.in b/libgomp/testsuite/Makefile.in
index d743e464cdc..4155350cf80 100644
--- a/libgomp/testsuite/Makefile.in
+++ b/libgomp/testsuite/Makefile.in
@@ -147,7 +147,6 @@ CFLAGS = @CFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
 CPU_COUNT = @CPU_COUNT@
-CXX = @CXX@
 CYGPATH_W = @CYGPATH_W@
 DEFS = @DEFS@
 DEPDIR = @DEPDIR@
@@ -215,6 +214,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
 XLDFLAGS = @XLDFLAGS@
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 2f9e538278f..1c4af9a8a2c 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -91,19 +91,6 @@ proc libgomp_init { args } {
       setenv LANG C.ASCII
     }
 
-    if { $blddir != "" } {
-	# Fix up '-funconfigured-libstdc++-v3' in 'GXX_UNDER_TEST' (see
-	# '../../configure.ac').
-	set flags_file "${blddir}/../libstdc++-v3/scripts/testsuite_flags"
-	if { [file exists $flags_file] } {
-	    set flags [exec sh $flags_file --build-includes]
-	    verbose -log "GXX_UNDER_TEST = $GXX_UNDER_TEST"
-	    set GXX_UNDER_TEST [string map [list \
-	      " -funconfigured-libstdc++-v3 " " $flags " \
-					   ] $GXX_UNDER_TEST]
-	    verbose -log "GXX_UNDER_TEST = $GXX_UNDER_TEST"
-	}
-    }
     if ![info exists GCC_UNDER_TEST] then {
 	if [info exists TOOL_EXECUTABLE] {
 	    set GCC_UNDER_TEST $TOOL_EXECUTABLE
@@ -185,6 +172,11 @@ proc libgomp_init { args } {
 
     set ALWAYS_CFLAGS ""
     if { $blddir != "" } {
+	# If '--with-build-sysroot=[...]' was specified, use it for build-tree
+	# testing.
+	global SYSROOT_CFLAGS_FOR_TARGET
+	lappend ALWAYS_CFLAGS "additional_flags=${SYSROOT_CFLAGS_FOR_TARGET}"
+
         lappend ALWAYS_CFLAGS "additional_flags=-B${blddir}/"
         # targets that use libgomp.a%s in their specs need a -B option
         # for uninstalled testing.
diff --git a/libgomp/testsuite/libgomp-site-extra.exp.in b/libgomp/testsuite/libgomp-site-extra.exp.in
index c824d85f7ed..8de14f48976 100644
--- a/libgomp/testsuite/libgomp-site-extra.exp.in
+++ b/libgomp/testsuite/libgomp-site-extra.exp.in
@@ -1,4 +1,2 @@
 set FLOCK {@FLOCK@}
-set GCC_UNDER_TEST {@CC@}
-set GXX_UNDER_TEST {@CXX@}
-set GFORTRAN_UNDER_TEST {@FC@}
+set SYSROOT_CFLAGS_FOR_TARGET {@SYSROOT_CFLAGS_FOR_TARGET@}
diff --git a/libgomp/testsuite/libgomp.c++/c++.exp b/libgomp/testsuite/libgomp.c++/c++.exp
index 8b4563b1d0d..ed096e17b9c 100644
--- a/libgomp/testsuite/libgomp.c++/c++.exp
+++ b/libgomp/testsuite/libgomp.c++/c++.exp
@@ -15,6 +15,10 @@ if { $blddir != "" } {
     verbose -log "GXX_UNDER_TEST not defined, will not execute c++ tests"
     return
 }
+if { $blddir != "" } {
+    set lang_source_re {^.*\.[cC]$}
+    set lang_include_flags [exec sh ${blddir}/../libstdc++-v3/scripts/testsuite_flags --build-includes]
+}
 lappend ALWAYS_CFLAGS "compiler=$GXX_UNDER_TEST"
 
 # If a testcase doesn't have special options, use these.
@@ -44,6 +48,8 @@ set_ld_library_path_env_vars
 dg-runtest $tests "" $DEFAULT_CFLAGS
 
 if { $blddir != "" } {
+    unset lang_source_re
+    unset lang_include_flags
     unset libstdc++_library_path
     unset lang_library_paths
 }
diff --git a/libgomp/testsuite/libgomp.oacc-c++/c++.exp b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
index 79df401c99a..7b2315e406f 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/c++.exp
+++ b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
@@ -25,6 +25,10 @@ if { $blddir != "" } {
     verbose -log "GXX_UNDER_TEST not defined, will not execute c++ tests"
     return
 }
+if { $blddir != "" } {
+    set lang_source_re {^.*\.[cC]$}
+    set lang_include_flags [exec sh ${blddir}/../libstdc++-v3/scripts/testsuite_flags --build-includes]
+}
 lappend ALWAYS_CFLAGS "compiler=$GXX_UNDER_TEST"
 
 # Initialize dg.
@@ -121,6 +125,8 @@ foreach offload_target [concat [split $offload_targets ","] "disable"] {
 unset offload_target
 
 if { $blddir != "" } {
+    unset lang_source_re
+    unset lang_include_flags
     unset libstdc++_library_path
     unset lang_library_paths
 }
-- 
2.34.1

Re: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

[Maciej W. Rozycki]

Hi Thomas,

> Will you, Maciej, please test that this doesn't break your setting?

 Umm, this was implemented for my Western Digital development environment, 
which I don't have access to anymore.  I'll see what I can do, but it may 
be neither easy nor quick.  It's been long ago and I don't have a setup 
with multilibs enabled anymore.  And neither I remember the thorough 
problem analysis I went through that has led me to the conclusions.

 I've come across my note, in a reply to Chung-Lin's concerns, about using 
libgomp.exp as a standalone test driver.  Has this been verified somehow 
with your proposed change?

 Also I've skimmed over your change and this has caught my eye:

> diff --git a/libgomp/configure.ac b/libgomp/configure.ac
> index 1aad83a79da..49f7fb0dc82 100644
> --- a/libgomp/configure.ac
> +++ b/libgomp/configure.ac
> @@ -151,22 +151,11 @@ AC_SUBST(enable_static)
>  
>  AM_MAINTAINER_MODE
>  
> -# We optionally test libgomp C++ support, and for that want to use the proper
> -# C++ driver, 'g++' (or 'xg++' for build-tree testing).  Given that build of
> -# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we
> -# cannot make build of target libgomp depend on target libstdc++-v3: circular
> -# dependency.  We thus cannot instantiate 'AC_PROG_CXX' here: we'd get
> -# '-funconfigured-libstdc++-v3' (see '../configure.ac').  Therefore, just
> -# capture 'CXX', and we'll fix this up at 'make check' time (see
> -# 'testsuite/lib/libgomp.exp:libgomp_init').
> -AC_SUBST(CXX)
> -
>  # Create a spec file, so that compile/link tests don't fail
>  test -f libgfortran.spec || touch libgfortran.spec
>  FCFLAGS="$FCFLAGS -L."
>  
> -# We need 'gfortran' to compile parts of the library, and test libgomp Fortran
> -# support.
> +# We need gfortran to compile parts of the library
>  # We can't use AC_PROG_FC because it expects a fully working gfortran.

-- missing full stop here, and I suggest to just make all this comment one 
paragraph (I can't imagine why it's not already, as the second sentence is 
clearly a continuation of the first one).

 I think a proper change description would be good too, as otherwise one 
may wonder why you have removed all the stuff above, and what this change 
is about anyway.

  Maciej

Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] (was: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951])

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

Hi!

On 2023-06-02T11:52:04+0200, I wrote:
> On 2020-01-14T21:31:13+0800, Chung-Lin Tang <chunglin_tang@mentor.com> wrote:
>> I understand your situation with --with-build-sysroot/--without-sysroot, [...]
>>
>> Can you test if the attached patch works for you? The patch exports the build sysroot
>> setting from the toplevel to target library subdirs, and adds the --sysroot= option
>> when doing build-tree testing [...]
>
> Belatedly: thanks, I like that approach better indeed.
>
> This is, by the way, in line with what GCC compiler testing is doing;
> 'gcc/Makefile.in':
>
>     # Set if the compiler was configured with --with-build-sysroot.
>     SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
>
>     # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation.
>     # They are passed first to allow individual tests to override them.
>             @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp
>
> That is, via 'site.exp', put 'SYSROOT_CFLAGS_FOR_TARGET' into
> 'TEST_ALWAYS_FLAGS', which is "passed to every compilation".
>
>> [...], if this does work, then other library testsuites (e.g. libatomic.exp) might
>> also need considering updating, I think.
>
> Correct.  (I'm offering to take care of that.)

First, regarding the top-level build system part:

>> 2020-01-14  Chung-Lin Tang  <cltang@codesourcery.com>
>>
>>       * Makefile.tpl  (NORMAL_TARGET_EXPORTS): Add export of
>>       SYSROOT_CFLAGS_FOR_TARGET variable.
>>       * Makefile.in:  Regenerate.

>> --- Makefile.tpl      (revision 279954)
>> +++ Makefile.tpl      (working copy)
>> @@ -322,6 +322,7 @@ RAW_CXX_TARGET_EXPORTS = \
>>
>>  NORMAL_TARGET_EXPORTS = \
>>       $(BASE_TARGET_EXPORTS) \
>> +     SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
>>       CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
>
> With that one moved into the generic 'BASE_TARGET_EXPORTS', [...]

Pushed to master branch commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a
"Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951]",
see attached.


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Pass-SYSROOT_CFLAGS_FOR_TARGET-down-to-target-librar.patch --]
[-- Type: text/x-diff, Size: 1914 bytes --]

From d1bff1ba4d470f6723be83c0e3c4d5083e51877a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu, 1 Jun 2023 23:07:37 +0200
Subject: [PATCH] Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries
 [PR109951]

..., where we need to use it (separate commits) for build-tree testing, similar
to 'gcc/Makefile.in:site.exp':

    # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation.
    # They are passed first to allow individual tests to override them.
    	@echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp

	PR testsuite/109951
	* Makefile.tpl (BASE_TARGET_EXPORTS): Add
	'SYSROOT_CFLAGS_FOR_TARGET'.
	* Makefile.in: Regenerate.

Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
---
 Makefile.in  | 1 +
 Makefile.tpl | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Makefile.in b/Makefile.in
index c97130a2338..2f136839c35 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -321,6 +321,7 @@ BASE_TARGET_EXPORTS = \
 	RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
 	READELF="$(READELF_FOR_TARGET)"; export READELF; \
 	STRIP="$(STRIP_FOR_TARGET)"; export STRIP; \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
 	WINDMC="$(WINDMC_FOR_TARGET)"; export WINDMC; \
 @if gcc-bootstrap
diff --git a/Makefile.tpl b/Makefile.tpl
index 36fa20950d4..5872dd03f2c 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -324,6 +324,7 @@ BASE_TARGET_EXPORTS = \
 	RANLIB="$(RANLIB_FOR_TARGET)"; export RANLIB; \
 	READELF="$(READELF_FOR_TARGET)"; export READELF; \
 	STRIP="$(STRIP_FOR_TARGET)"; export STRIP; \
+	SYSROOT_CFLAGS_FOR_TARGET="$(SYSROOT_CFLAGS_FOR_TARGET)"; export SYSROOT_CFLAGS_FOR_TARGET; \
 	WINDRES="$(WINDRES_FOR_TARGET)"; export WINDRES; \
 	WINDMC="$(WINDMC_FOR_TARGET)"; export WINDMC; \
 @if gcc-bootstrap
-- 
2.34.1

libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951] (was: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951])

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

Hi!

On 2023-06-03T21:32:57+0100, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>> Will you, Maciej, please test that this doesn't break your setting?
>
>  Umm, this was implemented for my Western Digital development environment,
> which I don't have access to anymore.  I'll see what I can do, but it may
> be neither easy nor quick.  It's been long ago and I don't have a setup
> with multilibs enabled anymore.  And neither I remember the thorough
> problem analysis I went through that has led me to the conclusions.

I see.  I've therefore myself now done a quick hack to replicate the
original requirement, to verify that given '--with-build-sysroot=',
build-tree testing must have '--sysroot=[...]' appear for every driver
invocation:

    --- gcc/gcc.cc
    +++ gcc/gcc.cc
    @@ -8190,6 +8190,10 @@ driver::main (int argc, char **argv)
       if (!maybe_print_and_exit ())
         return 0;

    +  if (!env.get ("SKIP_VERIFY_SYSROOT"))
    +    if (!(target_system_root && !strcmp (target_system_root, "/boot/..")))
    +      internal_error ("MISSING SYSROOT");
    +
       early_exit = prepare_infiles ();
       if (early_exit)
         return get_exit_code ();

With that, build GCC with '--with-build-sysroot=/boot/..' and with the
environment variable 'SKIP_VERIFY_SYSROOT' set (to ignore any build-time
issues, not relevant to this discussion here), and test without the
'SKIP_VERIFY_SYSROOT' environment variable set (meaning the checking is
active).  I observe that with current (un-altered) GCC sources,
'--sysroot=[...]' doesn't actually appear for all compiler test suites;
the following ones FAIL:

  - 'ada/acats/acats.sum'
  - 'testsuite/g++/g++.sum': 'g++.dg/plugin/plugin.exp' only
  - 'testsuite/gcc/gcc.sum': 'gcc.dg/plugin/plugin.exp' only
  - 'gm2/gm2.sum'
  - 'gnat/gnat.sum'
  - 'obj-c++/obj-c++.sum': 'obj-c++.dg/plugin/plugin.exp' only
  - 'objc/objc.sum': 'objc.dg/plugin/plugin.exp' only

Additionally, the following target library test suite also FAILs:

    'libitm/testsuite/libitm.sum'

(Resolving these is not my objective right now; I suppose these were not
relevant in Maciej's original scenario.)

Otherwise, I observe that my proposed re-work does still achieve the
desired outcome re '--sysroot=[...]', and Iain has long ago confirmed
that it does resolve <https://gcc.gnu.org/PR109951>
"libgomp, testsuite: non-native multilib c++ tests fail on Darwin", so
pushed to master branch commit fb5d27be272b71fb9026224535fc73f125ce3be7
"libgomp: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951]",
see attached.


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-libgomp-Consider-with-build-sysroot-.-for-target-lib.patch --]
[-- Type: text/x-diff, Size: 9686 bytes --]

From fb5d27be272b71fb9026224535fc73f125ce3be7 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Thu, 1 Jun 2023 23:07:37 +0200
Subject: [PATCH] libgomp: Consider '--with-build-sysroot=[...]' for target
 libraries' build-tree testing (instead of build-time 'CC' etc.) [PR91884,
 PR109951]

This is commit c8e759b4215ba4b376c9d468aeffe163b3d520f0 (Subversion r279708)
"libgomp/test: Fix compilation for build sysroot" and follow-up
commit 749bd22ddc50b5112e5ed506ffef7249bf8e6fb3
"libgomp/test: Remove a build sysroot fix regression" done differently,
avoiding build-tree testing use of any random gunk that may appear in
build-time 'CC', 'CXX', 'FC'.

	PR testsuite/91884
	PR testsuite/109951
	libgomp/
	* configure.ac: Revert earlier changes, instead
	'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
	* Makefile.in: Regenerate.
	* configure: Likewise.
	* testsuite/Makefile.in: Likewise.
	* testsuite/lib/libgomp.exp (libgomp_init): Remove
	"Fix up '-funconfigured-libstdc++-v3' in 'GXX_UNDER_TEST'" code.
	If '--with-build-sysroot=[...]' was specified, use it for
	build-tree testing.
	* testsuite/libgomp-site-extra.exp.in (GCC_UNDER_TEST)
	(GXX_UNDER_TEST, GFORTRAN_UNDER_TEST): Don't set.
	(SYSROOT_CFLAGS_FOR_TARGET): Set.
	* testsuite/libgomp.c++/c++.exp (lang_source_re)
	(lang_include_flags): Set for build-tree testing.
	* testsuite/libgomp.oacc-c++/c++.exp (lang_source_re)
	(lang_include_flags): Likewise.

Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
---
 libgomp/Makefile.in                         |  2 +-
 libgomp/configure                           | 17 ++++-------------
 libgomp/configure.ac                        | 15 +++------------
 libgomp/testsuite/Makefile.in               |  2 +-
 libgomp/testsuite/lib/libgomp.exp           | 18 +++++-------------
 libgomp/testsuite/libgomp-site-extra.exp.in |  4 +---
 libgomp/testsuite/libgomp.c++/c++.exp       |  6 ++++++
 libgomp/testsuite/libgomp.oacc-c++/c++.exp  |  6 ++++++
 8 files changed, 27 insertions(+), 43 deletions(-)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 3ef05e6a3cb..431bc87b629 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -368,7 +368,6 @@ CFLAGS = @CFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
 CPU_COUNT = @CPU_COUNT@
-CXX = @CXX@
 CYGPATH_W = @CYGPATH_W@
 DEFS = @DEFS@
 DEPDIR = @DEPDIR@
@@ -436,6 +435,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
 XLDFLAGS = @XLDFLAGS@
diff --git a/libgomp/configure b/libgomp/configure
index a12b30f1b0f..498bc084a86 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -656,6 +656,7 @@ tmake_file
 XLDFLAGS
 XCFLAGS
 config_path
+SYSROOT_CFLAGS_FOR_TARGET
 FLOCK
 CPU_COUNT
 LIBGOMP_BUILD_VERSIONED_SHLIB_SUN_FALSE
@@ -679,7 +680,6 @@ libtool_VERSION
 ac_ct_FC
 FCFLAGS
 FC
-CXX
 MAINT
 MAINTAINER_MODE_FALSE
 MAINTAINER_MODE_TRUE
@@ -11808,22 +11808,11 @@ fi
 
 
 
-# We optionally test libgomp C++ support, and for that want to use the proper
-# C++ driver, 'g++' (or 'xg++' for build-tree testing).  Given that build of
-# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we
-# cannot make build of target libgomp depend on target libstdc++-v3: circular
-# dependency.  We thus cannot instantiate 'AC_PROG_CXX' here: we'd get
-# '-funconfigured-libstdc++-v3' (see '../configure.ac').  Therefore, just
-# capture 'CXX', and we'll fix this up at 'make check' time (see
-# 'testsuite/lib/libgomp.exp:libgomp_init').
-
-
 # Create a spec file, so that compile/link tests don't fail
 test -f libgfortran.spec || touch libgfortran.spec
 FCFLAGS="$FCFLAGS -L."
 
-# We need 'gfortran' to compile parts of the library, and test libgomp Fortran
-# support.
+# We need gfortran to compile parts of the library
 # We can't use AC_PROG_FC because it expects a fully working gfortran.
 #AC_PROG_FC(gfortran)
 case `echo $GFORTRAN` in
@@ -16580,6 +16569,8 @@ fi
 
 fi
 
+
+
 # Get target configury.
 . ${srcdir}/configure.tgt
 CFLAGS="$save_CFLAGS $XCFLAGS"
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 1aad83a79da..49f7fb0dc82 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -151,22 +151,11 @@ AC_SUBST(enable_static)
 
 AM_MAINTAINER_MODE
 
-# We optionally test libgomp C++ support, and for that want to use the proper
-# C++ driver, 'g++' (or 'xg++' for build-tree testing).  Given that build of
-# target libstdc++-v3 depends on target libgomp (see '../Makefile.def'), we
-# cannot make build of target libgomp depend on target libstdc++-v3: circular
-# dependency.  We thus cannot instantiate 'AC_PROG_CXX' here: we'd get
-# '-funconfigured-libstdc++-v3' (see '../configure.ac').  Therefore, just
-# capture 'CXX', and we'll fix this up at 'make check' time (see
-# 'testsuite/lib/libgomp.exp:libgomp_init').
-AC_SUBST(CXX)
-
 # Create a spec file, so that compile/link tests don't fail
 test -f libgfortran.spec || touch libgfortran.spec
 FCFLAGS="$FCFLAGS -L."
 
-# We need 'gfortran' to compile parts of the library, and test libgomp Fortran
-# support.
+# We need gfortran to compile parts of the library
 # We can't use AC_PROG_FC because it expects a fully working gfortran.
 #AC_PROG_FC(gfortran)
 case `echo $GFORTRAN` in
@@ -356,6 +345,8 @@ if test -z "$FLOCK"; then
   AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
 fi
 
+AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
+
 # Get target configury.
 . ${srcdir}/configure.tgt
 CFLAGS="$save_CFLAGS $XCFLAGS"
diff --git a/libgomp/testsuite/Makefile.in b/libgomp/testsuite/Makefile.in
index d743e464cdc..4155350cf80 100644
--- a/libgomp/testsuite/Makefile.in
+++ b/libgomp/testsuite/Makefile.in
@@ -147,7 +147,6 @@ CFLAGS = @CFLAGS@
 CPP = @CPP@
 CPPFLAGS = @CPPFLAGS@
 CPU_COUNT = @CPU_COUNT@
-CXX = @CXX@
 CYGPATH_W = @CYGPATH_W@
 DEFS = @DEFS@
 DEPDIR = @DEPDIR@
@@ -215,6 +214,7 @@ SED = @SED@
 SET_MAKE = @SET_MAKE@
 SHELL = @SHELL@
 STRIP = @STRIP@
+SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
 VERSION = @VERSION@
 XCFLAGS = @XCFLAGS@
 XLDFLAGS = @XLDFLAGS@
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index a143b5d0def..cab926a798b 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -91,19 +91,6 @@ proc libgomp_init { args } {
       setenv LANG C.ASCII
     }
 
-    if { $blddir != "" } {
-	# Fix up '-funconfigured-libstdc++-v3' in 'GXX_UNDER_TEST' (see
-	# '../../configure.ac').
-	set flags_file "${blddir}/../libstdc++-v3/scripts/testsuite_flags"
-	if { [file exists $flags_file] } {
-	    set flags [exec sh $flags_file --build-includes]
-	    verbose -log "GXX_UNDER_TEST = $GXX_UNDER_TEST"
-	    set GXX_UNDER_TEST [string map [list \
-	      " -funconfigured-libstdc++-v3 " " $flags " \
-					   ] $GXX_UNDER_TEST]
-	    verbose -log "GXX_UNDER_TEST = $GXX_UNDER_TEST"
-	}
-    }
     if ![info exists GCC_UNDER_TEST] then {
 	if [info exists TOOL_EXECUTABLE] {
 	    set GCC_UNDER_TEST $TOOL_EXECUTABLE
@@ -185,6 +172,11 @@ proc libgomp_init { args } {
 
     set ALWAYS_CFLAGS ""
     if { $blddir != "" } {
+	# If '--with-build-sysroot=[...]' was specified, use it for build-tree
+	# testing.
+	global SYSROOT_CFLAGS_FOR_TARGET
+	lappend ALWAYS_CFLAGS "additional_flags=${SYSROOT_CFLAGS_FOR_TARGET}"
+
         lappend ALWAYS_CFLAGS "additional_flags=-B${blddir}/"
         # targets that use libgomp.a%s in their specs need a -B option
         # for uninstalled testing.
diff --git a/libgomp/testsuite/libgomp-site-extra.exp.in b/libgomp/testsuite/libgomp-site-extra.exp.in
index c824d85f7ed..8de14f48976 100644
--- a/libgomp/testsuite/libgomp-site-extra.exp.in
+++ b/libgomp/testsuite/libgomp-site-extra.exp.in
@@ -1,4 +1,2 @@
 set FLOCK {@FLOCK@}
-set GCC_UNDER_TEST {@CC@}
-set GXX_UNDER_TEST {@CXX@}
-set GFORTRAN_UNDER_TEST {@FC@}
+set SYSROOT_CFLAGS_FOR_TARGET {@SYSROOT_CFLAGS_FOR_TARGET@}
diff --git a/libgomp/testsuite/libgomp.c++/c++.exp b/libgomp/testsuite/libgomp.c++/c++.exp
index 8b4563b1d0d..ed096e17b9c 100644
--- a/libgomp/testsuite/libgomp.c++/c++.exp
+++ b/libgomp/testsuite/libgomp.c++/c++.exp
@@ -15,6 +15,10 @@ if { $blddir != "" } {
     verbose -log "GXX_UNDER_TEST not defined, will not execute c++ tests"
     return
 }
+if { $blddir != "" } {
+    set lang_source_re {^.*\.[cC]$}
+    set lang_include_flags [exec sh ${blddir}/../libstdc++-v3/scripts/testsuite_flags --build-includes]
+}
 lappend ALWAYS_CFLAGS "compiler=$GXX_UNDER_TEST"
 
 # If a testcase doesn't have special options, use these.
@@ -44,6 +48,8 @@ set_ld_library_path_env_vars
 dg-runtest $tests "" $DEFAULT_CFLAGS
 
 if { $blddir != "" } {
+    unset lang_source_re
+    unset lang_include_flags
     unset libstdc++_library_path
     unset lang_library_paths
 }
diff --git a/libgomp/testsuite/libgomp.oacc-c++/c++.exp b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
index 79df401c99a..7b2315e406f 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/c++.exp
+++ b/libgomp/testsuite/libgomp.oacc-c++/c++.exp
@@ -25,6 +25,10 @@ if { $blddir != "" } {
     verbose -log "GXX_UNDER_TEST not defined, will not execute c++ tests"
     return
 }
+if { $blddir != "" } {
+    set lang_source_re {^.*\.[cC]$}
+    set lang_include_flags [exec sh ${blddir}/../libstdc++-v3/scripts/testsuite_flags --build-includes]
+}
 lappend ALWAYS_CFLAGS "compiler=$GXX_UNDER_TEST"
 
 # Initialize dg.
@@ -121,6 +125,8 @@ foreach offload_target [concat [split $offload_targets ","] "disable"] {
 unset offload_target
 
 if { $blddir != "" } {
+    unset lang_source_re
+    unset lang_include_flags
     unset libstdc++_library_path
     unset lang_library_paths
 }
-- 
2.34.1