https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tschwinge at gcc dot gnu.org
--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 56178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56178&action=edit
0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch
(In reply to Xiao Ma from comment #0)
> Recently, I wanted to port an open source gpgpu target (a custom
> modification of RISCV) to GCC/openmp (Following the approach of gcu and
> nvptx, using offloading (https://gcc.gnu.org/wiki/Offloading)).
Interesting! Please keep us posted how this works out.
> However, the
> upstream after this patch
> (https://github.com/mxlol233-ventus/gcc/commit/
> 3496ca4e6566fc3c5f1093a0290bb88c34d368f8#diff-
> 98b71abedd6e59eb80cb43e75ebb507ffa8bf540ee88aa099c6c7fe7cf90ae3e),
> NUM_POLY_INT_COEFFS became greater than 1, while for the x86-64-*-* target,
> NUM_POLY_INT_COEFFS=1. This makes it impossible for a RISC-V*-*-* lto1 to
> parse the data in the LTO sections (e.g. gnu.offload_lto_*) of the object
> files generated by x86-64-*-*.
I'm not sure about your initial analysis; I'm not familiar with the
code/changes you cite.
However, please try building with the attached
'0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch'. If that triggers, we've
(likely...) found (one of) your issue(s).
