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

[PATCH v2 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 passing the `--tool_exec' option to `runtest' 
via $(AM_RUNTESTFLAGS) with $(CC) as the argument, 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/
	* testsuite/Makefile.am (AM_RUNTESTFLAGS): New variable.
	* testsuite/Makefile.in: Regenerate.
---
Changes from v1:

- Remove testsuite/libatomic-test-support.exp.in and the associated 
  changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libatomic/testsuite/Makefile.am |    1 +
 libatomic/testsuite/Makefile.in |    1 +
 2 files changed, 2 insertions(+)

patches/gcc-test-libatomic-runtestflags-tool-exec.diff
Index: gcc/libatomic/testsuite/Makefile.am
===================================================================
--- gcc.orig/libatomic/testsuite/Makefile.am
+++ gcc/libatomic/testsuite/Makefile.am
@@ -11,3 +11,4 @@ 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)
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
Index: gcc/libatomic/testsuite/Makefile.in
===================================================================
--- gcc.orig/libatomic/testsuite/Makefile.in
+++ gcc/libatomic/testsuite/Makefile.in
@@ -278,6 +278,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 	     echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
 all: all-am
 
 .SUFFIXES:

[PATCH v2 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 passing the `--tool_exec' option to `runtest' 
via $(AM_RUNTESTFLAGS) with $(CC) as the argument, 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

For consistency with other top-level target libraries also respect the 
GCC_UNDER_TEST TCL variable, which can be set e.g. with an argument to 
`runtest' in a standalone run.  Finally remove an unused TOOL_OPTIONS 
TCL variable instance.

	libffi/
	* testsuite/Makefile.am (AM_RUNTESTFLAGS): Add `--tool_exec' 
	option.
	* testsuite/Makefile.in: Regenerate.
	* testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST 
	and TOOL_EXECUTABLE.
	(libffi_target_compile): Use GCC_UNDER_TEST.
---
Changes from v1:

- Remove testsuite/libffi-test-support.exp.in and the associated changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libffi/testsuite/Makefile.am    |    2 +-
 libffi/testsuite/Makefile.in    |    2 +-
 libffi/testsuite/lib/libffi.exp |   16 ++++++++++++++--
 3 files changed, 16 insertions(+), 4 deletions(-)

gcc-test-libffi-runtestflags-tool-exec.diff
Index: gcc/libffi/testsuite/Makefile.am
===================================================================
--- gcc.orig/libffi/testsuite/Makefile.am
+++ gcc/libffi/testsuite/Makefile.am
@@ -11,7 +11,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 	       echo $(top_srcdir)/../dejagnu/runtest ; \
 	    else echo runtest; fi`
 
-AM_RUNTESTFLAGS =
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
 
 CLEANFILES = *.exe core* *.log *.sum
 
Index: gcc/libffi/testsuite/Makefile.in
===================================================================
--- gcc.orig/libffi/testsuite/Makefile.in
+++ gcc/libffi/testsuite/Makefile.in
@@ -134,7 +134,7 @@ ALLOCA = @ALLOCA@
 AMTAR = @AMTAR@
 AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
 AM_LTLDFLAGS = @AM_LTLDFLAGS@
-AM_RUNTESTFLAGS = 
+AM_RUNTESTFLAGS = --tool_exec "$(CC)"
 AR = @AR@
 AUTOCONF = @AUTOCONF@
 AUTOHEADER = @AUTOHEADER@
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"

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

[Maciej W. Rozycki]

Hi,

 This is v2 of patch series, originally posted here:

<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/msg00769.html>
<https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>

meant to address 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.

 Julian reported an issue triggered in his standalone test environment by 
the original version of the libgomp part of this patch series, which is 
one of the two patches from the series that have been already applied.

 The cause has been the newly-added definition of GCC_UNDER_TEST embedded 
in the generated libgomp/testsuite/libgomp-test-support.exp configuration 
file, which is used in Julian's setup which also relies on the invocation 
of `[find_gcc]' to locate the correct compiler to use.

 This invocation is unsuitable for in-tree testing as we want to use 
exactly the same compiler invocation, as recorded in $(CC), as used to 
build the library.  So I have worked with Chung-Lin on a replacement 
version, which would work with such standalone testing while still 
satisfying the original requirement to use $(CC).

 In the end I have decided to use the documented `--tool_exec' option to 
`runtest' to contain the change within the testsuite's Makefile and its 
`check' goal, which is inherent to the build tree and as such not supposed 
to be used in standalone testing, like with `contrib/test_installed'.

 I am quite sure the problem is specific to libgomp only, as it's the only 
of the four libraries handled that had a preexisting *-test-support.exp 
test configuration file, and the remaining three only got one with the 
changes from the series.  However to keep things consistent across the 
tree I propose to use the `--tool_exec' option for all four libraries.

 This in particular means reverting the whole of the libgomp change as 
well as a part of the libgo change, both already applied, in addition to 
making further adjustments.  For libatomic and libffi this updated 
proposal merely replaces the original one.

 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.

 I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
remaining ones to the GCC repo?

  Maciej

[PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression

[Maciej W. Rozycki]

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation 
for build sysroot") that caused a regression in some standalone test 
environments where testsuite/libgomp-test-support.exp is used, but the 
compiler is expected to be determined by `[find_gcc]', and use the 
`--tool_exec' option to `runtest' passed via $(AM_RUNTESTFLAGS) with 
$(CC) as the argument rather than the GCC_UNDER_TEST TCL variable in 
testsuite/libgomp-test-support.exp.

	libgomp/
	* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove 
	variable.
	* testsuite/Makefile.am (AM_RUNTESTFLAGS): New variable.
	* testsuite/Makefile.in: Regenerate.
---
Applies on top of v1.
---
 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
@@ -310,6 +310,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@"

[PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot

[Maciej W. Rozycki]

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler 
when using build sysroot") and use the `--tool_exec' option to `runtest' 
via $(AM_RUNTESTFLAGS) with $(GOC) as the argument rather than the 
GOC_UNDER_TEST TCL variable to set the compiler to use with the test 
suite, for consistency with the other top-level GCC target libraries.  
Update testsuite/lib/libgo.exp to actually handle the option by using 
the TOOL_EXECUTABLE TCL variable.

	libgo/
	* configure.ac: Remove testsuite/libgo-test-support.exp from 
	output files.
	* configure: Regenerate.
	* testsuite/libgo-test-support.exp.in: Remove file.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): Remove
	variable.
	(AM_RUNTESTFLAGS): Add `--tool_exec' option.
	* testsuite/Makefile.in: Regenerate.
	* testsuite/lib/libgo.exp: Handle TOOL_EXECUTABLE.
---
Applies on top of v1.
---
 libgo/configure                           |    3 +--
 libgo/configure.ac                        |    2 +-
 libgo/testsuite/Makefile.am               |    4 +---
 libgo/testsuite/Makefile.in               |    7 ++-----
 libgo/testsuite/lib/libgo.exp             |   12 ++++++++----
 libgo/testsuite/libgo-test-support.exp.in |   17 -----------------
 6 files changed, 13 insertions(+), 32 deletions(-)

gcc-test-libgo-runtestflags-tool-exec.diff
Index: gcc/libgo/configure
===================================================================
--- gcc.orig/libgo/configure
+++ gcc/libgo/configure
@@ -15880,7 +15880,7 @@ else
   multilib_arg=
 fi
 
-ac_config_files="$ac_config_files Makefile testsuite/Makefile testsuite/libgo-test-support.exp"
+ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
 
 ac_config_commands="$ac_config_commands default"
@@ -17061,7 +17061,6 @@ do
     "libtool") CONFIG_COMMANDS="$CONFIG_COMMANDS libtool" ;;
     "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
     "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
-    "testsuite/libgo-test-support.exp") CONFIG_FILES="$CONFIG_FILES testsuite/libgo-test-support.exp" ;;
     "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
Index: gcc/libgo/configure.ac
===================================================================
--- gcc.orig/libgo/configure.ac
+++ gcc/libgo/configure.ac
@@ -889,7 +889,7 @@ else
   multilib_arg=
 fi
 
-AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-test-support.exp)
+AC_CONFIG_FILES(Makefile testsuite/Makefile)
 
 AC_CONFIG_COMMANDS([default],
 [if test -n "$CONFIG_FILES"; then
Index: gcc/libgo/testsuite/Makefile.am
===================================================================
--- gcc.orig/libgo/testsuite/Makefile.am
+++ gcc/libgo/testsuite/Makefile.am
@@ -11,13 +11,11 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 	       echo $(top_srcdir)/../dejagnu/runtest ; \
 	    else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
-
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
 # overrides it, so use of GCC_EXEC_PREFIX will not result in using GCC files
 # from the install tree.
 
-AM_RUNTESTFLAGS = "TEST_GCC_EXEC_PREFIX=$(libdir)/gcc"
+AM_RUNTESTFLAGS = --tool_exec "$(GOC)" "TEST_GCC_EXEC_PREFIX=$(libdir)/gcc"
 
 CLEANFILES = *.log *.sum
Index: gcc/libgo/testsuite/Makefile.in
===================================================================
--- gcc.orig/libgo/testsuite/Makefile.in
+++ gcc/libgo/testsuite/Makefile.in
@@ -107,7 +107,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES = libgo-test-support.exp
+CONFIG_CLEAN_FILES =
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -300,13 +300,12 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 	       echo $(top_srcdir)/../dejagnu/runtest ; \
 	    else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
 # overrides it, so use of GCC_EXEC_PREFIX will not result in using GCC files
 # from the install tree.
-AM_RUNTESTFLAGS = "TEST_GCC_EXEC_PREFIX=$(libdir)/gcc"
+AM_RUNTESTFLAGS = --tool_exec "$(GOC)" "TEST_GCC_EXEC_PREFIX=$(libdir)/gcc"
 CLEANFILES = *.log *.sum
 all: all-am
 
@@ -340,8 +339,6 @@ $(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):
-libgo-test-support.exp: $(top_builddir)/config.status $(srcdir)/libgo-test-support.exp.in
-	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
 	-rm -f *.lo
Index: gcc/libgo/testsuite/lib/libgo.exp
===================================================================
--- gcc.orig/libgo/testsuite/lib/libgo.exp
+++ gcc/libgo/testsuite/lib/libgo.exp
@@ -17,11 +17,15 @@
 set TESTING_IN_BUILD_TREE 1
 
 if ![info exists GOC_UNDER_TEST] then {
-    set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-    if {$gccdir != ""} {
-	set gccdir [file dirname $gccdir]
+    if [info exists TOOL_EXECUTABLE] {
+	set GOC_UNDER_TEST $TOOL_EXECUTABLE
+    } else {
+	set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+	if {$gccdir != ""} {
+	    set gccdir [file dirname $gccdir]
+	}
+	set GOC_UNDER_TEST "$gccdir/gccgo -B$gccdir/"
     }
-    set GOC_UNDER_TEST "$gccdir/gccgo -B$gccdir/"
 }
 
 if [info exists GOTEST_TMPDIR] {
Index: gcc/libgo/testsuite/libgo-test-support.exp.in
===================================================================
--- gcc.orig/libgo/testsuite/libgo-test-support.exp.in
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright (C) 2019 Free Software Foundation, Inc.
-
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 3 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with GCC; see the file COPYING3.  If not see
-# <http://www.gnu.org/licenses/>.
-
-set GOC_UNDER_TEST {@GOC@}

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

[Mike Stump]

On Feb 13, 2020, at 3:36 PM, Maciej W. Rozycki <macro@wdc.com> wrote:
> 
> This is v2 of patch series, originally posted here:
> 
> <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/msg00769.html>
> <https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00770.html>
> 
> meant to address 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.

> In the end I have decided to use the documented `--tool_exec' option to 
> `runtest' to contain the change within the testsuite's Makefile and its 
> `check' goal, which is inherent to the build tree and as such not supposed 
> to be used in standalone testing, like with `contrib/test_installed'.


> I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
> remaining ones to the GCC repo?

So, I really, really would like to avoid additional arguments like this.  I'd prefer that instead you push content into the built site.exp from the Makefile, or something else like this, and then use that content as you need to.  This preserves the ability to go where you need to in the tree, and do a runtest without specifying the option.

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

[Maciej W. Rozycki]

Mike, Chung-Lin --

> > In the end I have decided to use the documented `--tool_exec' option to 
> > `runtest' to contain the change within the testsuite's Makefile and its 
> > `check' goal, which is inherent to the build tree and as such not supposed 
> > to be used in standalone testing, like with `contrib/test_installed'.
> 
> 
> > I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
> > remaining ones to the GCC repo?
> 
> So, I really, really would like to avoid additional arguments like this.  
> I'd prefer that instead you push content into the built site.exp from 
> the Makefile, or something else like this, and then use that content as 
> you need to.  This preserves the ability to go where you need to in the 
> tree, and do a runtest without specifying the option.

 Thank you, Mike, for your input.  That is what v1 did, but it seems to 
clash with some people's expectations, as discussed here:

<https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00057.html>

So it looks like we have conflicting expectations for the desired 
arrangement, and of course the current situation isn't right either.

 Or, Chung-Lin, will you be happy if we just stay away from 
libgomp/testsuite/libgomp-test-support.exp and use say 
libgomp/testsuite/libgomp-test-support-extra.exp to supply the compiler 
setting (EXTRA_DEJAGNU_SITE_CONFIG supports an arbitrary number of 
site.exp fragments)?

 Any other proposals?

  Maciej

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

[Mike Stump]

On Feb 14, 2020, at 11:57 AM, Maciej W. Rozycki <macro@wdc.com> wrote:
> 
> Mike, Chung-Lin --
> 
>>> In the end I have decided to use the documented `--tool_exec' option to 
>>> `runtest' to contain the change within the testsuite's Makefile and its 
>>> `check' goal, which is inherent to the build tree and as such not supposed 
>>> to be used in standalone testing, like with `contrib/test_installed'.
>> 
>> 
>>> I'm assuming Ian will take care of the 3/4 libgo change; OK to apply the 
>>> remaining ones to the GCC repo?
>> 
>> So, I really, really would like to avoid additional arguments like this.  
>> I'd prefer that instead you push content into the built site.exp from 
>> the Makefile, or something else like this, and then use that content as 
>> you need to.  This preserves the ability to go where you need to in the 
>> tree, and do a runtest without specifying the option.
> 
> Thank you, Mike, for your input.  That is what v1 did, but it seems to 
> clash with some people's expectations, as discussed here:
> 
> <https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00057.html>

I didn't see any clash with expectations.  They expect in the build tree testing to work, they expect install testing to work.  I expect both, you expect both; I just don't think we differ on this.  Where I think things went wrong is there is a change to their testing environment that you didn't fully account for in your patch. You didn't intend to break it, but there is just a little more work to be done to not break it, that's all.

So, let step back.  You want to change the options to the compiler, right?

So, imagine for a second that site.exp has those options, then you can reliably grab them from that file and use them, no?  If so, then all you have to do is put the content you need into site.exp, and then once it is there, you can then merely add a little code to grab them and add them, right?

So, pick testsuite that fails, and that you broke.  Back out the last patch, and instead, in the Makefile (or whatever generate the Makefile, look for the site.exp rule, and instead pilfer the data you want create it up into an existing variable, if relevant to it, and if not, create a new one.

For some of these files we see they come from automake, so we google, then we find:

http://gnu-automake.7480.n7.nabble.com/Automake-and-dejagnu-s-site-exp-file-td4414.html

and presto, a 5 line solution to an existing problem.

Is that kinda sort similar to what you want to do?  Now that's a 12 year old answer the the problem, I didn't check to see if there is a newer answer.  It looks reasonable enough.

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

[Maciej W. Rozycki]

On Fri, 14 Feb 2020, Mike Stump wrote:

> > Thank you, Mike, for your input.  That is what v1 did, but it seems to 
> > clash with some people's expectations, as discussed here:
> > 
> > <https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00057.html>
> 
> I didn't see any clash with expectations.  They expect in the build tree 
> testing to work, they expect install testing to work.  I expect both, 
> you expect both; I just don't think we differ on this.  Where I think 
> things went wrong is there is a change to their testing environment that 
> you didn't fully account for in your patch. You didn't intend to break 
> it, but there is just a little more work to be done to not break it, 
> that's all.
> 
> So, let step back.  You want to change the options to the compiler, 
> right?
> 
> So, imagine for a second that site.exp has those options, then you can 
> reliably grab them from that file and use them, no?  If so, then all you 
> have to do is put the content you need into site.exp, and then once it 
> is there, you can then merely add a little code to grab them and add 
> them, right?
> 
> So, pick testsuite that fails, and that you broke.  Back out the last 
> patch, and instead, in the Makefile (or whatever generate the Makefile, 
> look for the site.exp rule, and instead pilfer the data you want create 
> it up into an existing variable, if relevant to it, and if not, create a 
> new one.
> 
> For some of these files we see they come from automake, so we google, 
> then we find:
> 
> http://gnu-automake.7480.n7.nabble.com/Automake-and-dejagnu-s-site-exp-file-td4414.html
> 
> and presto, a 5 line solution to an existing problem.
> 
> Is that kinda sort similar to what you want to do?  Now that's a 12 year 
> old answer the the problem, I didn't check to see if there is a newer 
> answer.  It looks reasonable enough.

 Huh?  That's exactly what v1 did, it added:

set GCC_UNDER_TEST {@CC@}

(with @CC@ substituted by `configure' of course) to `site.exp' produced by 
`make check' (as constructed by `automake'[1]).  That caused Julian and 
Chung-Lin trouble.

 So I don't really know what you are talking about or trying to suggest 
me; AFAICT your idea was already tried and failed (though Chung-Lin may 
provide further input I asked for that may help).

References:

[1] <https://www.gnu.org/software/automake/manual/html_node/DejaGnu-Tests.html>

  Maciej

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

[Maciej W. Rozycki]

On Sat, 15 Feb 2020, Maciej W. Rozycki wrote:

> > > Thank you, Mike, for your input.  That is what v1 did, but it seems to 
> > > clash with some people's expectations, as discussed here:
> > > 
> > > <https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00057.html>
> > 
> > I didn't see any clash with expectations.  They expect in the build tree 
> > testing to work, they expect install testing to work.  I expect both, 
> > you expect both; I just don't think we differ on this.  Where I think 
> > things went wrong is there is a change to their testing environment that 
> > you didn't fully account for in your patch. You didn't intend to break 
> > it, but there is just a little more work to be done to not break it, 
> > that's all.

 FAOD the clash with expectations is in that you want a fix in `site.exp' 
while Chung-Lin wants one outside `site.exp'.  The status quo does not 
clash with either of you, but it does not meet my requirements, though I 
don't care where the fix goes.  I hope this makes things clear here.

  Maciej