From: "Maciej W. Rozycki" <macro@wdc.com>
To: Julian Brown <julian@codesourcery.com>
Cc: Mike Stump <mikestump@comcast.net>,
gcc-patches@gcc.gnu.org,
Thomas Schwinge <thomas@codesourcery.com>
Subject: Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot
Date: Mon, 06 Jan 2020 15:25:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.21.2001061459150.30965@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <20200103113421.51b55ff5@squid.athome>
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
next prev parent reply other threads:[~2020-01-06 15:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 18:12 [PATCH " Maciej W. Rozycki
2019-11-11 18:12 ` [PATCH 2/4] libffi/test: Fix " Maciej W. Rozycki
2019-11-11 18:12 ` [PATCH 1/4] libatomic/test: " Maciej W. Rozycki
2019-11-11 18:23 ` [golang-dev] [PATCH 0/4] Fix library testsuite " Ulderico Cirello
2019-11-11 18:29 ` Kaz Kylheku (libffi)
2019-11-11 18:42 ` Ian Lance Taylor
2019-11-11 18:35 ` Ian Lance Taylor
2019-11-11 18:45 ` Maciej W. Rozycki
2019-11-11 23:29 ` Ian Lance Taylor
2019-11-11 18:44 ` Maciej W. Rozycki
2019-11-26 15:56 ` [PING][PATCH " Maciej W. Rozycki
2019-12-02 14:49 ` [PING^2][PATCH " Maciej W. Rozycki
2019-12-09 21:30 ` [PING^3][PATCH " Maciej W. Rozycki
2019-12-17 0:06 ` [PING^4][PATCH " Maciej W. Rozycki
2019-12-21 1:30 ` Mike Stump
2019-12-22 1:34 ` Maciej W. Rozycki
2020-01-03 11:34 ` Julian Brown
2020-01-06 15:25 ` Maciej W. Rozycki [this message]
2020-01-09 21:00 ` Tobias Burnus
2020-01-14 13:43 ` Chung-Lin Tang
2020-01-21 3:21 ` Maciej W. Rozycki
2020-01-31 22:36 ` Maciej W. Rozycki
2020-02-11 8:35 ` Chung-Lin Tang
2020-02-11 21:31 ` Maciej W. Rozycki
2023-06-02 9:52 ` Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] Thomas Schwinge
2023-06-03 20:32 ` Maciej W. Rozycki
2023-09-12 9:35 ` 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
2023-09-12 9:35 ` Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] " Thomas Schwinge
2020-01-06 15:47 ` [PING^5][PATCH 0/4] Fix library testsuite compilation for build sysroot Maciej W. Rozycki
2020-01-13 21:20 ` [PING^6][PATCH " Maciej W. Rozycki
2020-01-21 2:44 ` [PING^7][PATCH " Maciej W. Rozycki
2020-01-26 21:07 ` Jeff Law
2020-02-13 23:37 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.21.2001061459150.30965@redsun52.ssa.fujisawa.hgst.com \
--to=macro@wdc.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=julian@codesourcery.com \
--cc=mikestump@comcast.net \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).