mbox series

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

Message ID alpine.LFD.2.21.2002271413200.18621@redsun52.ssa.fujisawa.hgst.com
Headers show
Series Fix library testsuite compilation for build sysroot | expand

Message

Maciej W. Rozycki Feb. 28, 2020, 1:17 a.m. UTC 
Hi,

 This is v3 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>

and then reposted as v2 here:

<https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00827.html>
<https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00828.html>
<https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00829.html>
<https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00830.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.

 There were concerns raised by Julian and Chung-Lin about the libgomp 
change in v1 where an issue triggered in their standalone test environment 
and the wrong compiler executable was chosen.  To address this issue in v2 
I proposed to use the `--tool_exec' option to `runtest' to choose the 
compiler, however Mike expressed concerns about this approach causing 
troubles where `runtest' is invoked standalone rather than via `make'.

 I have outlined yet another (third) approach in:

<https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00874.html>

and I have since realised that the generated 
`libgomp/testsuite/libgomp-test-support.exp' configuration file is not 
used with the usual automake's mechanism defined to supply cnofiguration 
files to DejaGNU.  Consequently this v3 of the series implements my third 
approach and I am fairly sure (and certainly do hope) it will satisfy 
everyone involved.

 This goes back to v1 for most of the matter and brings back the use of 
GCC_UNDER_TEST (or GOC_UNDER_TEST) supplied via `site.exp' to choose the 
compiler to use for testing.  However for consistency the file to keep 
this setting is in v3 called `*-site-extra.exp' rather than 
`*-test-support.exp'.

 For 1/4 (libatomic) and 2/4 (libffi) this is the only change made 
compared to v1, and v1 series has already been approved by Mike here:

<https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01506.html>

and Jeff here:

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

These two patches were uncontroversial and the file name change can be 
considered trivial, so I am going to apply v3 of these patches shortly 
unless I hear objections.

 For 3/4 (libgo), where v1 has been already applied, v3 renames 
`libgo-site-extra.exp' to `libgo-test-support.exp' and also brings support 
for the `--tool_exec' option to `runtest', to keep testsuite things 
consistent across top-level target libraries.  I'm leaving it up to Ian to 
decide if he wants things arranged like this in libgo.

 For 4/4 (libgomp) some Makefile infrastructure changes are required along 
the lines of 1/4 and 2/4 to wire in `libgomp-site-extra.exp'; for these I 
request explicit approval before I push them.

 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; any objections 
about 1/4 and 2/4, and OK to apply 4/4 to the GCC repo?

 Finally, apologies for the confusion my earlier oversight with 
`libgomp/testsuite/libgomp-test-support.exp' wiring may have caused.

  Maciej