* [PATCH v2 1/4] libatomic/test: Fix compilation for build sysroot
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 2/4] libffi/test: Fix " Maciej W. Rozycki
@ 2020-02-13 23:36 ` Maciej W. Rozycki
2020-02-13 23:37 ` [PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression Maciej W. Rozycki
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-13 23:36 UTC (permalink / raw)
To: gcc-patches
Cc: Julian Brown, Tobias Burnus, Jeff Law, Thomas Schwinge,
Mike Stump, Chung-Lin Tang, Ian Lance Taylor
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:
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 2/4] libffi/test: Fix compilation for build sysroot
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
@ 2020-02-13 23:36 ` Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 1/4] libatomic/test: " Maciej W. Rozycki
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-13 23:36 UTC (permalink / raw)
To: gcc-patches
Cc: Julian Brown, Tobias Burnus, Jeff Law, Thomas Schwinge,
Mike Stump, Chung-Lin Tang, Ian Lance Taylor
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"
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
@ 2020-02-13 23:36 Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 2/4] libffi/test: Fix " Maciej W. Rozycki
` (4 more replies)
0 siblings, 5 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-13 23:36 UTC (permalink / raw)
To: gcc-patches
Cc: Julian Brown, Tobias Burnus, Jeff Law, Thomas Schwinge,
Mike Stump, Chung-Lin Tang, Ian Lance Taylor
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 2/4] libffi/test: Fix " Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 1/4] libatomic/test: " Maciej W. Rozycki
@ 2020-02-13 23:37 ` Maciej W. Rozycki
2020-02-13 23:37 ` [PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot Maciej W. Rozycki
2020-02-14 19:12 ` [PATCH v2 0/4] Fix library testsuite compilation " Mike Stump
4 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-13 23:37 UTC (permalink / raw)
To: gcc-patches
Cc: Julian Brown, Tobias Burnus, Jeff Law, Thomas Schwinge,
Mike Stump, Chung-Lin Tang, Ian Lance Taylor
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@"
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
` (2 preceding siblings ...)
2020-02-13 23:37 ` [PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression Maciej W. Rozycki
@ 2020-02-13 23:37 ` Maciej W. Rozycki
2020-02-14 19:12 ` [PATCH v2 0/4] Fix library testsuite compilation " Mike Stump
4 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-13 23:37 UTC (permalink / raw)
To: gcc-patches
Cc: Julian Brown, Tobias Burnus, Jeff Law, Thomas Schwinge,
Mike Stump, Chung-Lin Tang, Ian Lance Taylor
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@}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
` (3 preceding siblings ...)
2020-02-13 23:37 ` [PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot Maciej W. Rozycki
@ 2020-02-14 19:12 ` Mike Stump
2020-02-14 19:57 ` Maciej W. Rozycki
4 siblings, 1 reply; 10+ messages in thread
From: Mike Stump @ 2020-02-14 19:12 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: gcc-patches, Julian Brown, Tobias Burnus, Jeff Law,
Thomas Schwinge, Chung-Lin Tang, Ian Lance Taylor
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
2020-02-14 19:12 ` [PATCH v2 0/4] Fix library testsuite compilation " Mike Stump
@ 2020-02-14 19:57 ` Maciej W. Rozycki
2020-02-14 22:16 ` Mike Stump
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-14 19:57 UTC (permalink / raw)
To: Mike Stump, Chung-Lin Tang
Cc: gcc-patches, Julian Brown, Tobias Burnus, Jeff Law,
Thomas Schwinge, Ian Lance Taylor
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
2020-02-14 19:57 ` Maciej W. Rozycki
@ 2020-02-14 22:16 ` Mike Stump
2020-02-15 1:47 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Mike Stump @ 2020-02-14 22:16 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Chung-Lin Tang, gcc-patches, Julian Brown, Tobias Burnus,
Jeff Law, Thomas Schwinge, Ian Lance Taylor
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
2020-02-14 22:16 ` Mike Stump
@ 2020-02-15 1:47 ` Maciej W. Rozycki
2020-02-17 17:19 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-15 1:47 UTC (permalink / raw)
To: Mike Stump
Cc: Chung-Lin Tang, gcc-patches, Julian Brown, Tobias Burnus,
Jeff Law, Thomas Schwinge, Ian Lance Taylor
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot
2020-02-15 1:47 ` Maciej W. Rozycki
@ 2020-02-17 17:19 ` Maciej W. Rozycki
0 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-02-17 17:19 UTC (permalink / raw)
To: Mike Stump
Cc: Chung-Lin Tang, gcc-patches, Julian Brown, Tobias Burnus,
Jeff Law, Thomas Schwinge, Ian Lance Taylor
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-02-17 17:19 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-13 23:36 [PATCH v2 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 2/4] libffi/test: Fix " Maciej W. Rozycki
2020-02-13 23:36 ` [PATCH v2 1/4] libatomic/test: " Maciej W. Rozycki
2020-02-13 23:37 ` [PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression Maciej W. Rozycki
2020-02-13 23:37 ` [PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot Maciej W. Rozycki
2020-02-14 19:12 ` [PATCH v2 0/4] Fix library testsuite compilation " Mike Stump
2020-02-14 19:57 ` Maciej W. Rozycki
2020-02-14 22:16 ` Mike Stump
2020-02-15 1:47 ` Maciej W. Rozycki
2020-02-17 17:19 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).