| Message ID | alpine.DEB.2.10.1502171619550.19294@digraph.polyomino.org.uk |
|---|---|
| State | New |
| Headers | show |
On Tue, Feb 17, 2015 at 04:21:06PM +0000, Joseph Myers wrote: > On Tue, 17 Feb 2015, Jakub Jelinek wrote: > > > Third attempt failed with: > > ../../../libgcc/config/nvptx/realloc.c:24:20: fatal error: stdlib.h: No such file or directory > > compilation terminated. > > ../../../libgcc/static-object.mk:17: recipe for target 'realloc.o' failed > > make[2]: *** [realloc.o] Error 1 > > make[2]: *** Waiting for unfinished jobs.... > > make[2]: Leaving directory '/usr/src/gcc/objnvptx/nvptx-none/libgcc' > > I have nvptx-newlib symlinked into the gcc tree as newlib, so I expected it > > would be built in-tree, is that not the case (at least wiki/Offloading > > mentions that). Or is it just that libgcc can't really have dependencies on > > newlib headers as newlib is built after libgcc? > > I've committed this patch to fix this last issue (the header dependence, > that is; I don't know about the in-tree build). Thanks, sure, libgcc now builds fine, the in-tree build fails: configure:4261: checking for C compiler default output file name configure:4283: /usr/src/gcc/objnvptx/./gcc/xgcc -B/usr/src/gcc/objnvptx/./gcc/ -nostdinc -B/usr/src/gcc/objnvptx/nvptx-none/newlib/ -isystem /usr/src/gcc/objnvptx/nvptx-none/newlib/targ-include -isystem /usr/src/gcc/newlib/libc/include -B/usr/local/nvptx-none/bin/ -B/usr/local/nvptx-none/lib/ -isystem /usr/local/nvptx-none/include -isystem /usr/local/nvptx-none/sys-include -g -O2 conftest.c >&5 error opening libc.a collect2: error: ld returned 1 exit status very early during in-tree newlib configure. Jakub
Hi! On Tue, 17 Feb 2015 17:40:33 +0100, Jakub Jelinek <jakub@redhat.com> wrote: > On Tue, Feb 17, 2015 at 04:21:06PM +0000, Joseph Myers wrote: > > On Tue, 17 Feb 2015, Jakub Jelinek wrote: > > > I have nvptx-newlib symlinked into the gcc tree as newlib, so I expected it > > > would be built in-tree, is that not the case (at least wiki/Offloading > > > mentions that). > configure:4261: checking for C compiler default output file name > configure:4283: /usr/src/gcc/objnvptx/./gcc/xgcc -B/usr/src/gcc/objnvptx/./gcc/ -nostdinc -B/usr/src/gcc/objnvptx/nvptx-none/newlib/ -isystem /usr/src/gcc/objnvptx/nvptx-none/newlib/targ-include -isystem /usr/src/gcc/newlib/libc/include -B/usr/local/nvptx-none/bin/ -B/usr/local/nvptx-none/lib/ -isystem /usr/local/nvptx-none/include -isystem /usr/local/nvptx-none/sys-include -g -O2 conftest.c >&5 > error opening libc.a > collect2: error: ld returned 1 exit status > very early during in-tree newlib configure. 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? Grüße, Thomas
On Wed, Feb 18, 2015 at 10:12:19AM +0100, Thomas Schwinge wrote: > On Tue, 17 Feb 2015 17:40:33 +0100, Jakub Jelinek <jakub@redhat.com> wrote: > > On Tue, Feb 17, 2015 at 04:21:06PM +0000, Joseph Myers wrote: > > > On Tue, 17 Feb 2015, Jakub Jelinek wrote: > > > > I have nvptx-newlib symlinked into the gcc tree as newlib, so I expected it > > > > would be built in-tree, is that not the case (at least wiki/Offloading > > > > mentions that). > > > configure:4261: checking for C compiler default output file name > > configure:4283: /usr/src/gcc/objnvptx/./gcc/xgcc -B/usr/src/gcc/objnvptx/./gcc/ -nostdinc -B/usr/src/gcc/objnvptx/nvptx-none/newlib/ -isystem /usr/src/gcc/objnvptx/nvptx-none/newlib/targ-include -isystem /usr/src/gcc/newlib/libc/include -B/usr/local/nvptx-none/bin/ -B/usr/local/nvptx-none/lib/ -isystem /usr/local/nvptx-none/include -isystem /usr/local/nvptx-none/sys-include -g -O2 conftest.c >&5 > > error opening libc.a > > collect2: error: ld returned 1 exit status > > very early during in-tree newlib configure. > > 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? My bad. Yes, that does resolve the issue, make & make install now worked for nvptx-none for me with the patches (2 from Bernd, my mode_table, my t-nvptx). Can you or Bernd comment on the other issues I've raised, i.e. whether you are going to apply Bernd's approved patches, on the t-nvptx fix? I'll try to have a look at the va_list stuff, if it blocks everything rather than just testcases with va_list being offloaded. Jakub
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? 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. ../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, but 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. Jakub
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
On Wed, Feb 18, 2015 at 01:09:53PM +0100, Thomas Schwinge wrote: > 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? Your wording is fine, but should be listed on wiki/Offloading and doc/install.texi perhaps too? > > 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? Toplevel configure.ac has: # If LTO is enabled, add the LTO front end. if test "$enable_lto" = "yes" ; then case ,${enable_languages}, in *,lto,*) ;; *) enable_languages="${enable_languages},lto" ;; esac if test "${build_lto_plugin}" = "yes" ; then configdirs="$configdirs lto-plugin" fi fi so IMHO we want similar snippet for the --enable-as-accelerator-for= case, perhaps right below this one. Not building lto FE for the accelerator compilers make them completely useless, thus I think we really want to do that automatically. > 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. Can you adjust that to add a cgraph flag alongside of the offloadable instead and use that instead of the attribute? Jakub
Index: libgcc/config/nvptx/realloc.c =================================================================== --- libgcc/config/nvptx/realloc.c (revision 220763) +++ libgcc/config/nvptx/realloc.c (working copy) @@ -21,8 +21,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see <http://www.gnu.org/licenses/>. */ -#include <stdlib.h> -#include <string.h> +#include <stddef.h> #include "nvptx-malloc.h" void * @@ -44,7 +43,7 @@ __nvptx_realloc (void *ptr, size_t newsz) oldsz = *sp; } if (oldsz != 0) - memcpy (newptr, ptr, oldsz > newsz ? newsz : oldsz); + __builtin_memcpy (newptr, ptr, oldsz > newsz ? newsz : oldsz); __nvptx_free (ptr); return newptr;