https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937
--- Comment #5 from Xiao Ma <mxlol233 at outlook dot com> --- yes. handle the lto reading process is simple: just make the binary block jump steps is same as the host's num_poly value. 获取Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: rguenth at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> Sent: Tuesday, October 24, 2023 3:27:52 PM To: mxlol...@outlook.com <mxlol...@outlook.com> Subject: [Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org, | |rsandifo at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- The host and the target compiler have to be "similar" enough for the LTO bytecode to be transferable. May I suggest to use aarch64 with SVE as host instead? I fear differing NUM_POLY_INT_COEFFS is almost impossible to support. Well, we could maybe stream NUM_POLY_INT_COEFFS and adjust reading to rewrite to the target supported number - rewriting from 1 to 2 should be possible but I'm not sure how to handle the reverse ... -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
