Hi Jakub! (Will respond to your other questions later.)
On Wed, 18 Feb 2015 12:34:38 +0100, Jakub Jelinek <ja...@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
pgpfvZAJm6VWf.pgp
Description: PGP signature
