Created attachment 57578 [details] aarch64 to nvptx offloading example When offloading to nvptx target from aarch64 host, I'm getting following error: $ g++ -fopenmp -foffload=nvptx-none offload_example.c _ in pp_quoted_string, at pretty-print.cc:2266 0x1a1e34f pp_quoted_string /git/gcc/gcc/pretty-print.cc:2266 0x1a2025b pp_format(pretty_printer*, text_info*, urlifier const*) /git/gcc/gcc/pretty-print.cc:1623 0x19fc5fb diagnostic_context::report_diagnostic(diagnostic_info*) /git/gcc/gcc/diagnostic.cc:1604 0x19fc92f diagnostic_impl /git/gcc/gcc/diagnostic.cc:1767 0x1a00383 fatal_error(unsigned int, char const*, ...) /git/gcc/gcc/diagnostic.cc:2210 0xb22897 lto_input_mode_table(lto_file_decl_data*) /git/gcc/gcc/lto-streamer-in.cc:2121 0x6e6677 lto_file_finalize /git/gcc/gcc/lto/lto-common.cc:2276 0x6e6677 lto_create_files_from_ids /git/gcc/gcc/lto/lto-common.cc:2300 0x6e6677 lto_file_read /git/gcc/gcc/lto/lto-common.cc:2355 0x6e6677 read_cgraph_and_symbols(unsigned int, char const**) /git/gcc/gcc/lto/lto-common.cc:2803 0x6c4f8b lto_main() /git/gcc/gcc/lto/lto.cc:654 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. nvptx mkoffload: fatal error: aarch64-linux-gnu-accel-nvptx-none-gcc returned 1 exit status ... which I understand is due to different NUM_POLY_INT_COEFFS values; aarch64 defines it to be 2 while nvptx defaults to 1 According https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937#c4, it seems that such host-target combination is currently not supported. I understand translating from 2 to 1 is not a trivial undertaking. But this is still a technological limitation which prevents aarch64 host to nvptx target offloading which is otherwise possible. What can be done for supporting this combination in the long term? In the meanwhile are there any workarounds? e.g. if for a particular march, if poly_int can be expressed using 1 coefficient or -msve-vector-bits=128 is set, can NUM_POLY_INT_COEFFS be defined to that granularity? Thank you
Dup. *** This bug has been marked as a duplicate of bug 96265 ***
(In reply to Prachi Godbole from comment #0) > In the meanwhile are there any workarounds? e.g. if for a particular march, > if poly_int can be expressed using 1 coefficient or -msve-vector-bits=128 is > set, can NUM_POLY_INT_COEFFS be defined to that granularity? I doubt it since NUM_POLY_INT_COEFFS is a hard coded at compile time rather than a runtime switch.