Hi, This is v4 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> v2 posted 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> and v3 posted here: <https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01592.html> <https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01593.html> <https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01594.html> <https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01595.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. In the course of discussion it has been determined it might be the best if we sync with libffi rather than providing our replacement solution, as the upstream version has it addressed, although in a slightly messy way. I have therefore decided to clean it up with upstream libffi and propose a corresponding backport of the change to be included with our version. This has resulted in two patches actually, replacing 2/4 from the original series. The remaining changes are the same as in v3, however Chung-Lin has since confirmed the libgomp change proposed here has addressed issues with testing in his environment (thank you, Chung-Lin!). 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 4/5 libgo change (Ian, it's up to you if you want to have it or not). Any objections about 1/5 previously approved by Jeff, and OK to apply 2/5 and 3/5 (if the corresponding changes have been accepted into upstream libffi), as well as 5/5 to the GCC repo? Maciej
