https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114174
Bug ID: 114174
Summary: [aarch64] Offloading to nvptx-none
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: pgodbole at nvidia dot com
Target Milestone: ---
Created attachment 57578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57578&action=edit
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
