Re: nvptx offloading patches [3/n], RFD

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi Jakub!

(Will respond to your other questions later.)


On Wed, 18 Feb 2015 12:34:38 +0100, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Feb 18, 2015 at 10:12:19AM +0100, Thomas Schwinge wrote:
> > Do you literally have Ânvptx-newlib symlinked into the gcc tree as
> > newlibÂ?  If yes, then that should explain the problem: as I wrote in
> > <http://news.gmane.org/find-root.php?message_id=%3C87egq8mir1.fsf%40schwinge.name%3E>,
> > you need to Âadd a symbolic link to nvptx-newlib's newlib directory to
> > the directory containing the GCC sourcesÂ, so not link [GCC]/newlib ->
> > [newlib-nvptx], but [GCC]/newlib -> [newlib-nvptx]/newlib.  Does that
> > resolve the issue?

(It did.)  Can you suggest a better wording, to make this more clear in
the documentation?


> BTW, --with-cuda-driver-{include,lib} are apparently not documented in
> gcc/doc/ (--with-cuda-driver neither, but can't use that, as lib is
> /usr/local/cuda-6.5/lib64 in my case), and isn't documented on wiki/Offloading
> either.

Thanks for reporting; will fix that.


> ../configure --target=nvptx-none --enable-as-accelerator-for=x86_64-pc-linux-gnu --with-build-time-tools=/usr/src/gcc/objnvptxinst/usr/local/nvptx-none/bin --disable-sjlj-exceptions --enable-newlib-io-long-long
> make; make DESTDIR=/usr/src/gcc/objnvptxinst install
> 
> and
> 
> ../configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-offload-targets=nvptx-none=/usr/src/gcc/objnvptxinst --disable-bootstrap --with-cuda-driver-include=/usr/local/cuda-6.5/include --with-cuda-driver-lib=/usr/local/cuda-6.5/lib64
> make; make DESTDIR=/usr/src/gcc/objnvptxinst install
> 
> compilers now build

That looks very similar to what I'm using.  I currently install into
separate prefixes/DESTDIRS, because I have not yet verified that there
is no overlap in the installed files.


> offloading fails:
> 
> /usr/src/gcc/objnvptxinst/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.0.0//accel/nvptx-none/mkoffload @/tmp/cce9PdmR
> x86_64-pc-linux-gnu-accel-nvptx-none-gcc: error: language lto not recognized
> x86_64-pc-linux-gnu-accel-nvptx-none-gcc: error: language lto not recognized
> mkoffload: fatal error: /usr/src/gcc/objnvptxinst/usr/local/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
> compilation terminated.
> lto-wrapper: fatal error: /usr/src/gcc/objnvptxinst/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.0.0//accel/nvptx-none/mkoffload returned 1 exit status
> compilation terminated.
> /usr/bin/ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> 
> Is --enable-languages=c,c++,fortran,lto required when configuring the
> offload compiler?  It isn't required for intelmic.

Yes, exactly.  I assume the reason is that x86_64-intelmicemul-linux-gnu
defaults to supporting LTO, and due to this also defaults to building the
LTO front end.  I'll enhance the nvptx offloading documentation
accordingly.  Maybe we should add some "magic" to build the LTO front end
if --enable-as-accelerator-for=[...] has been specified?


Note that I recently added another prerequisite patch for nvptx
offloading to <https://gcc.gnu.org/wiki/Offloading#nvptx_Offloading>:
<http://news.gmane.org/find-root.php?message_id=%3C546CF508.9010807%40codesourcery.com%3E>.
If that is not applied, you'll get run-time errors because in
libgomp/plugin/plugin-nvptx.c:GOMP_OFFLOAD_get_table, cuModuleGetFunction
can't find main$_omp_fn$0 and similar symbols.


GrÃÃe,
 Thomas

Attachment: pgpHuEiWhnjON.pgp
Description: PGP signature