The nvptx-target usually is built on x86_64-linux-gnu, but searching the web you'll see that these GPUs are also used in aarch64-linux-gnu and powerpc64le-linux-gnu systems. building the nvptx offload compiler on powerpc64le, you see reasonable test results for libgomp, and I see at last one powerpc64le related commit: 2015-10-09 James Norris <jnorris@codesourcery.com> * config/rs6000/rs6000.c (rs6000_offload_options): New. (TARGET_OFFLOAD_OPTIONS): New. However adding an aarch64_offload_options hook doesn't look that well for AArch64, there are still two type of issues triggered in the testsuite: FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess errors) Excess errors: lto1: fatal error: nvptx-none - 0-bit integer numbers unsupported (mode 'SI') and: NRESOLVED: libgomp.c/../libgomp.c-c++-common/for-9.c compilation failed to produce executable UNSUPPORTED: libgomp.c/../libgomp.c-c++-common/function-not-offloaded-aux.c spawn -ignore SIGHUP /home/ubuntu/gcc-10-10.1.0/build/./gcc/xgcc -B/home/ubuntu/gcc-10-10.1.0/build/./gcc/ -B/usr/aarch64-linux-gnu/b in/ -B/usr/aarch64-linux-gnu/lib/ -isystem /usr/aarch64-linux-gnu/include -isystem /usr/aarch64-linux-gnu/sys-include -isystem /home/ ubuntu/gcc-10-10.1.0/build/sys-include -fchecking=1 offload_device_nonshared_as411951.c -B/home/ubuntu/gcc-10-10.1.0/build/aarch64-li nux-gnu/./libgomp/ -B/home/ubuntu/gcc-10-10.1.0/build/aarch64-linux-gnu/./libgomp/.libs -I/home/ubuntu/gcc-10-10.1.0/build/aarch64-li nux-gnu/./libgomp -I../../../../src/libgomp/testsuite/../../include -I../../../../src/libgomp/testsuite/.. -Lno -fmessage-length=0 -f no-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -B/home/ubuntu/gcc-10-10.1.0/debian/tmp-nvptx/usr/libexec/gcc/aarch64-li nux-gnu/10 -B/home/ubuntu/gcc-10-10.1.0/debian/tmp-nvptx/usr/bin -fopenmp -L/home/ubuntu/gcc-10-10.1.0/build/aarch64-linux-gnu/./libg omp/.libs -lm -o offload_device_nonshared_as411951.exe lto1: internal compiler error: bytecode stream: string too long for the string table 0x62559f string_for_index ../../src-nvptx/gcc/data-streamer-in.c:53 0x62559f bp_unpack_indexed_string(data_in*, bitpack_d*, unsigned int*) ../../src-nvptx/gcc/data-streamer-in.c:97 0x87a39b lto_input_mode_table(lto_file_decl_data*) ../../src-nvptx/gcc/lto-streamer-in.c:1685 0x5a076f lto_file_finalize ../../src-nvptx/gcc/lto/lto-common.c:2217 0x5a076f lto_create_files_from_ids ../../src-nvptx/gcc/lto/lto-common.c:2240 0x5a076f lto_file_read ../../src-nvptx/gcc/lto/lto-common.c:2295 0x5a076f read_cgraph_and_symbols(unsigned int, char const**) ../../src-nvptx/gcc/lto/lto-common.c:2747 0x58f523 lto_main() ../../src-nvptx/gcc/lto/lto.c:625 Please submit a full bug report, with preprocessed source if appropriate.
patch for the target hook posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550534.html
(Remove powerpc64le-linux-gnu from the summary as this PR is only about aarch64-linux and GCC is known to work on powerpc64le-linux-gnu.) (In reply to Matthias Klose from comment #1) > patch for the target hook posted at > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550534.html This patch has been committed on Fri Jul 24 16:17:44 2020 +0200 as https://gcc.gnu.org/g:29a14a1a907947fe9e43bce62d3468559f17da97
I think this issue and #111937 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937) have the same root cause: aarch64 also sets NUM_POLY_INT_COEFFS to 2, which makes it incompatible with the default value for nvptx (which is 1).
*** Bug 114174 has been marked as a duplicate of this bug. ***
Confirmed.
*** Bug 111937 has been marked as a duplicate of this bug. ***