This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (Problems with) coexistence of target and offloading compiler installations
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Ilya Verbin <iverbin at gmail dot com>, gcc at gcc dot gnu dot org, Matthias Klose <doko at debian dot org>
- Date: Fri, 10 Jun 2016 11:31:33 +0200
- Subject: Re: (Problems with) coexistence of target and offloading compiler installations
- Authentication-results: sourceware.org; auth=none
- References: <877fdxpk6h dot fsf at kepler dot schwinge dot homeip dot net>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jun 10, 2016 at 09:39:02AM +0200, Thomas Schwinge wrote:
> But I'm actually confused as to seeing libgomp.so in that list -- given
> the conflict of which compiler installations' libgomp.so "wins", I wonder
> how it can be working that some of the functions in there are supposed to
> behave differently on/are compiled differently for target vs. offloading
> target? Or did I do/understand something wrong? For a lot of other
For intelmic offloading, I believe all the libraries should be the same
(unless one chooses e.g. different tuning or ISA in between the two compiler
installations), including libgomp, so one should be able to just use the
libraries from the primary compiler. At least that has been the goal,
omp_is_initial_device should be handled by overriding the symbol in the
magic executable.
For emul certainly, for XeonPhi KNL PCIe HW, I haven't had a possibility to see
it in action yet, so I don't know how exactly is the filesystem typically
handled, if the offloading device has e.g. NFS mount of the host's
filesystem, or if all the libraries are always copied over on demand over
the bus, whatever.
Jakub