[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 --- Comment #5 from Xiao Ma --- 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 From:

[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 --- Comment #3 from Xiao Ma --- Created attachment 56185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56185&action=edit a patch on releases/gcc-13 to reproduce the bug. steps: 1. git clone -b releases/gcc-13 https://github.com/gcc-mirro

[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 --- Comment #2 from Xiao Ma --- (In reply to Thomas Schwinge from comment #1) > Created attachment 56178 [details] > 0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch > > (In reply to Xiao Ma from comment #0) > I'm not sure about your initial

[Bug target/96265] building nvptx-none on aarch64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265 Xiao Ma changed: What|Removed |Added CC||mxlol233 at outlook dot com --- Comment #3 fro

[Bug target/111937] New: [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 Bug ID: 111937 Summary: [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data. Product: gcc

[Bug rtl-optimization/111558] RISCV: shrink-wrapper optimization question

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111558 --- Comment #3 from Xiao Ma --- (In reply to Xiao Ma from comment #2) > For this piece of code, LLVM seems to be a bit concise: during the pass of > Prologue/Epilogue Insertion & Frame Finalization, it only inserts sd/ld > blocks in the entry an

[Bug rtl-optimization/111558] RISCV: shrink-wrapper optimization question

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111558 Xiao Ma changed: What|Removed |Added CC||mxlol233 at outlook dot com --- Comment #2 fr