[Bug target/111313] RISC-V: Incorrect vsetvl code gen for 2 level loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313 Li Pan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/111313] New: RISC-V: Incorrect code gen for 2 level loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313 Bug ID: 111313 Summary: RISC-V: Incorrect code gen for 2 level loop Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #5 from Li Pan --- Thank you, any thing I can help please feel free to let me know.

[Bug target/111720] RISC-V: Ugly codegen in RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720 --- Comment #27 from Li Pan --- Hi Richard and Juzhe. I investigated this issue recently and noticed that it may be related to the array size of the constant memory. Assume we have 2 functions as below. vuint8m1_t fn_0 () { uint8_t

[Bug c/112432] New: Internal-fn: The [i|l|ll]rint family don't support FLOATN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432 Bug ID: 112432 Summary: Internal-fn: The [i|l|ll]rint family don't support FLOATN Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #7 from Li Pan --- Seems no luck when --param vect-epilogues-nomask=0. I will have a try with the newest upstream for this issue if everything look OK, and keep you posted. ../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #8 from Li Pan --- Still fail in upstream. ../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv -mabi=lp64d \ -ftree-vectorize -O3 --param riscv-autovec-preference=fixed-vlmax \ --param

[Bug c/111970] New: [tree-optimization] SLP for non-IFN gathers result in RISC-V test failure on gather

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 Bug ID: 111970 Summary: [tree-optimization] SLP for non-IFN gathers result in RISC-V test failure on gather Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c/111970] [tree-optimization] SLP for non-IFN gathers result in RISC-V test failure on gather

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #1 from Li Pan --- Created attachment 56198 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56198=edit Without this commit

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #2 from Li Pan --- Add more information about how to build and run the test cases. Build: ../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv -mabi=lp64d -ftree-vectorize -O3 --param

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #3 from Li Pan --- Double confirmed the trunk of GCC still has this issue.

[Bug target/111720] RISC-V: Ugly codegen in RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720 --- Comment #14 from Li Pan --- Looks like option -fmerge-all-constants doesn't work for this case, as well as RISC-V. For RISC-V, the CLOBBER exists after tree gimple. void test (vuint8m1_t *out) { uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5,

[Bug target/110985] RISC-V: Incorrect code gen for RVV VLS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985 Li Pan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c/112432] Internal-fn: The [i|l|ll]rint family don't support FLOATN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432 --- Comment #5 from Li Pan --- (In reply to Li Pan from comment #4) > (In reply to Richard Biener from comment #3) > > Ah, yes, for lrint we have the builtins - I just looked for lceil here. So > > yeah, where there are

[Bug c/112432] Internal-fn: The [i|l|ll]rint family don't support FLOATN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432 Li Pan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c/109272] New: RISCV: vbool*_t better opportunities of code generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109272 Bug ID: 109272 Summary: RISCV: vbool*_t better opportunities of code generation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #6 from

[Bug c/109615] New: Redundant VSETVL after optimized code of RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109615 Bug ID: 109615 Summary: Redundant VSETVL after optimized code of RVV Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/109617] New: RISC-V: ICE for vlmul_ext_v intrinsic API

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109617 Bug ID: 109617 Summary: RISC-V: ICE for vlmul_ext_v intrinsic API Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug target/109479] [RISC-V] Build vint64m1_t with rv64gc_zve32x_zvl64b should promote information like "vint64m1_t requires the 'zve64x' extensions"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479 --- Comment #5 from Li Pan --- Thanks kito, update the title for clarification.

[Bug c/109479] New: [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479 Bug ID: 109479 Summary: [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug target/109479] [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479 --- Comment #2 from Li Pan --- Thanks for reminding me. Sorry for missing that and will pay more attention to this next time. The test case. #include "riscv_vector.h" vint64m1_t foo () { vint64m1_t v; return v; } According to the

[Bug c/110265] New: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110265 Bug ID: 110265 Summary: RISC-V: ICE when build RVV intrinsic with "-march=rv32gc_zve64d -mabi=ilp32d" Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug other/110744] [14 regression] cc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744 --- Comment #2 from Li Pan --- Hi there, Just try to reproduce this bug with powerPC cross compiler (sorry we don't have a real powerPC) with the below options. Unfortunately, I failed to reproduce this bug as above mentioned. Could you

[Bug other/110744] [14 regression] gcc.dg/tree-ssa/pr84512.c fails after r14-2267-gb8806f6ffbe72

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110744 --- Comment #7 from Li Pan --- Thanks a lot for the explanation, Kewen. Looks you are taking care of this already, anything is required from my-side please feel free to let me know.

[Bug target/109974] New: RISCV: RVV VSETVL Pass ICE in SLP auto-vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974 Bug ID: 109974 Summary: RISCV: RVV VSETVL Pass ICE in SLP auto-vectorization Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/110146] ICE in riscv_vector::function_builder::add_unique_function()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110146 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #1 from

[Bug c/110109] New: RISC-V: ICE when build the Intrinsic code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110109 Bug ID: 110109 Summary: RISC-V: ICE when build the Intrinsic code Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug target/110109] RISC-V: ICE when build the Intrinsic code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110109 --- Comment #1 from Li Pan --- GCC 13 doesn't have this issue.

[Bug c/110985] New: RISC-V: Incorrect code gen for RVV VLS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985 Bug ID: 110985 Summary: RISC-V: Incorrect code gen for RVV VLS Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/110299] New: RISC-V: ICE when build RVV intrinsic widen with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110299 Bug ID: 110299 Summary: RISC-V: ICE when build RVV intrinsic widen with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13. Product: gcc Version: 14.0

[Bug c/110277] New: RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110277 Bug ID: 110277 Summary: RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13. Product: gcc Version:

[Bug c/110277] RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110277 --- Comment #1 from Li Pan --- Meanwhile, the float reduction for FP16 is not well supported for both the ZVE64 and ZVE32. We will try to fix them together with this bug.

[Bug c/109748] New: RISC-V: Mis code gen for the

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748 Bug ID: 109748 Summary: RISC-V: Mis code gen for the Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug target/109748] RISC-V: Mis code gen for the RVV intrinsic VSETVL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748 --- Comment #2 from Li Pan --- No, should be introduced by one optimization of Juzhe in GCC 14. Juzhe is working on fixing this, just open a bug on behalf of Juzhe for tracking.

[Bug c/109773] New: RISC-V: ICE when build RVV Intrinisc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109773 Bug ID: 109773 Summary: RISC-V: ICE when build RVV Intrinisc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/109743] New: RISC-V: Unnecessary VSETVLI of the RVV intrinsic in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109743 Bug ID: 109743 Summary: RISC-V: Unnecessary VSETVLI of the RVV intrinsic in loop Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug target/112896] RISC-V: gcc.dg/pr30957-1.c run failure when rv64gcv_zvl1024b_zvfh_zfh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112896 Li Pan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #3 from

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #4 from Li Pan --- Just did some hacks from the riscv backend, which is to replace the expanding code of reduc_smax_scal_ to the reduc_xor_scal_. diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md index

[Bug c/113696] RISC-V: ineffective vsetvl behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113696 Li Pan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #18 from Li Pan --- Thanks for the confirmation. Yes, it was before expand. I will prepare one PATCH for this, and it should target for gcc-15 I bet.

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #19 from Li Pan --- (In reply to Robin Dapp from comment #7) > Here > > 0x105c6 vse8.v v8,(a5) > > is where we overwrite m. The vl is 128 but the preceding vsetvl gets a4 = > 46912504507016 as AVL which seems already

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #12 from Li Pan --- (In reply to Patrick O'Neill from comment #0) > Testcase: > int printf(char *, ...); > int a, b, l, i, p, q, t, n, o; > int *volatile c; > static int j; > static struct pack_1_struct d; > long e; > char m = 5; >

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #18 from Li Pan --- I see, thanks all, will have a try with variadic function call.

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #11 from

[Bug target/113247] RISC-V: Performance bug in SHA256 after enabling RVV vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113247 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #8 from

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #29 from Li Pan --- (In reply to Patrick O'Neill from comment #27) > Linking the discussion/plan here since more interested people are CCd here. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 > Using

[Bug target/113247] RISC-V: Performance bug in SHA256 after enabling RVV vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113247 --- Comment #10 from Li Pan --- (In reply to Robin Dapp from comment #9) > I also noticed this (likely unwanted) vector snippet and wondered where it > is being created. First I thought it's a vec_extract but doesn't look like > it. I'm going

[Bug target/113393] RISC-V: Full coverage test bugs for upstream 20240112

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113393 Li Pan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/113393] New: RISC-V: Full coverage test bugs for upstream 20240112

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113393 Bug ID: 113393 Summary: RISC-V: Full coverage test bugs for upstream 20240112 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/109615] Redundant VSETVL after optimized code of RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109615 Li Pan changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug c/113469] New: RISC-V: Illegal Insn for test case 920501-8.c when make linux for rv32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113469 Bug ID: 113469 Summary: RISC-V: Illegal Insn for test case 920501-8.c when make linux for rv32 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug target/110265] RISC-V: ICE when build RVV intrinsic integer reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110265 Li Pan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743 --- Comment #4 from Li Pan --- There may be another ICE for zve32f, will double-check about the details.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #8 from Li Pan --- For gcc.dg/torture/pr58955-2.c, we can simply reproduce it by options Pass when: -O3 Pass when: -O3 -ftracer -fno-schedule-insns -fno-schedule-insns2 Fail when: -O3 -ftracer -fno-schedule-insns2 10154:

[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743 --- Comment #6 from Li Pan --- Double confirmed the riscv-gnu-toolchain can be built successfully with the latest newlib.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #9 from Li Pan --- Before tracer - ENTRY | +---+ | B2 |

[Bug target/111720] RISC-V: Ugly codegen in RVV

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720 --- Comment #31 from Li Pan --- We still have some unnecessary code here, which is stack-related, will take care of it in another PATCH. After this patch: test: lui a5,%hi(.LANCHOR0) addia5,a5,%lo(.LANCHOR0)

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #12 from Li Pan --- Hi Robin, Do you have any ideas about the possible fix for this issue? The x86 backend has one workaround for this issue as below.

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #10 from Li Pan --- Link to one similar issue as below. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #14 from Li Pan --- The below diff similar to the x86 workaround looks not working, unless we change the `+m` to `=m`. But I don't fully test the impact of this change except the case itself. diff --git a/gcc/config/riscv/riscv.md

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 --- Comment #17 from Li Pan --- (In reply to Robin Dapp from comment #15) > Does the =m fix your issue? Or is the code gen different then and we're > just lucky? For my problem it doesn't help because we still don't recognize > an alias

[Bug c/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #1 from

[Bug c/112896] New: RISC-V: gcc.dg/pr30957-1.c run failure when rv64gcv_zvl1024b_zvfh_zfh

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112896 Bug ID: 112896 Summary: RISC-V: gcc.dg/pr30957-1.c run failure when rv64gcv_zvl1024b_zvfh_zfh Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c/113696] New: RISC-V: ineffective vsetvl behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113696 Bug ID: 113696 Summary: RISC-V: ineffective vsetvl behavior Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/113697] New: RISC-V: Redundant vsetvl insn in function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113697 Bug ID: 113697 Summary: RISC-V: Redundant vsetvl insn in function Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #7 from Li Pan --- RISC-V backend reproduce code, build with "-march=rv64gcv_zba_zbb_zbc_zbs --param=riscv-autovec-preference=fixed-vlmax -Ofast -ffast-math" typedef unsigned short uint16_t; void AAA (uint16_t *x, uint16_t *y,

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #13 from Li Pan --- I'll try to understand it and make it happen recently.

[Bug target/113697] RISC-V: Redundant vsetvl insn in function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113697 Li Pan changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug target/113469] RISC-V: Illegal Insn for test case 920501-8.c when make linux for rv32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113469 Li Pan changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #16 from Li Pan --- I have a try like below and finally have the Standard Name "SAT_ADD". Could you please help to double-check if my understanding is correct? Given below example code below: typedef unsigned int uint32_t;

[Bug target/113766] ICE: in generate_insn, at config/riscv/riscv-vector-builtins.cc:4186 with (invalid?) __riscv_vfredosum_tu()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766 --- Comment #1 from Li Pan --- Thanks, I will take care of it.

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #15 from Li Pan --- (In reply to Tamar Christina from comment #14) > Awesome! Feel free to reach out if you need any help. > > It’s likely easier to start with add and sub and get things pipe cleaned and > expand incrementally than

[Bug c/112432] Internal-fn: The [i|l|ll]rint family don't support FLOATN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432 --- Comment #4 from Li Pan --- (In reply to Richard Biener from comment #3) > Ah, yes, for lrint we have the builtins - I just looked for lceil here. So > yeah, where there are DEF_EXT_LIB_FLOATN_NX_BUILTINS we should have >

[Bug c/112432] Internal-fn: The [i|l|ll]rint family don't support FLOATN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432 --- Comment #2 from Li Pan --- (In reply to Richard Biener from comment #1) > Is there a corresponding C API? We don't have "generic" versions in > builtins.def either (with _VAR). > > That said, what's the testcase here? I found some FLOATN

[Bug tree-optimization/111970] [14 regression] SLP for non-IFN gathers result in RISC-V test failure on gather since r14-4745-gbeab5b95c58145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970 --- Comment #21 from Li Pan --- (In reply to Robin Dapp from comment #18) > I did a quick testsuite run on rv32 and can confirm that this fixes the > issue for me. Confirmed that this fixes the issue on RV64 too.

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #1 from Li Pan --- Confirmed with 1. build option '-march=rv64gcv -O3'. 2. riscv64-unknown-elf-gcc (GCC) 14.0.1 20240306 (experimental). If no one works on this ICE already, will take a look into it.

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #4 from Li Pan --- Hi Patrick, Could you please help to double-check if upstream has this problem? As well as PR114198. Thanks.

[Bug target/114352] RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352 Li Pan changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug c/114352] New: RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352 Bug ID: 114352 Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c/114351] New: RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351 Bug ID: 114351 Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c/114352] RISC-V: ICE when __attribute__((target("arch=+v")) and build with rv64gc -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352 --- Comment #1 from Li Pan --- Test GCC version: riscv64-unknown-elf-gcc (GCC) 14.0.1 20240315 (experimental) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #3 from Li Pan --- Testing a fix for possible regression.

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #2 from Li Pan --- Trigger below assert in vectorizable_store, the loop_vinfo use_partial, fully_masked and fully_lens are all true here. /* Shouldn't go with length-based approach if fully masked. */ gcc_assert (!loop_lens ||

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #10 from Li Pan --- The #define FUNCTION_VALUE_REGNO_P(N) ((N) == GP_RETURN || (N) == FP_RETURN) of the riscv backend doesn't honor vector mode. Then the below part 370 if

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #8 from Li Pan --- Find an even simpler code for reproduction. #include extern unsigned long get_vl (); vbool16_t test (vuint64m4_t a) { unsigned long b; return __riscv_vmsne_vx_u64m4_b16 (a, b, get_vl ()); }

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #7 from Li Pan --- Looks this commit from bisect acc22d56e140220e7dc6c138918cb6754b6d1c0b, will take a look into it.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #11 from Li Pan --- (In reply to Li Pan from comment #10) > The #define FUNCTION_VALUE_REGNO_P(N) ((N) == GP_RETURN || (N) == FP_RETURN) > of the riscv backend doesn't honor vector mode. Then the below part > > 370

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #12 from Li Pan --- #include extern unsigned long get_vl (); #if 0 #else vint32m1_t test (vint32m1_t a) { unsigned b; return __riscv_vadd_vx_i32m1 (a, b, get_vl ()); // No ICE } vbool16_t test (vuint64m4_t a) { unsigned

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #3 from Li Pan --- Reproduced from my side too.

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #5 from Li Pan --- (In reply to Kito Cheng from comment #4) > Reduced case: > ```c > typedef long c; > #pragma riscv intrinsic "vector" > template struct d {}; > struct e { > using f = d<0>; > }; > struct g { > using f = e::f;

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #13 from Li Pan --- overriding TARGET_CLASS_LIKELY_SPILLED_P hook may not be a fix as it will generate sorts of spill for the below sample code. vbool2_t test_vmfge_vf_f16m8_b2(vfloat16m8_t op1, float16_t op2, size_t vl) { return

[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 --- Comment #4 from Li Pan --- (In reply to Kito Cheng from comment #3) > Reduced case, not the final result, but it already run 8+ hours... > ``` > typedef int a; > typedef short b; > typedef unsigned c; > template < typename > using e =

[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #1 from

[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 --- Comment #2 from Li Pan --- The vzext.vf2 has earlyclobber dest operand, and then it cannot allocated to the source operand, like vzext.vf2 v0, v0. Thus we will fail when check_rtl. (define_insn "@pred__vf2" [(set (match_operand:VWEXTI 0

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #19 from Li Pan --- Thanks Juzhe. Here is another example - #include extern size_t get_new_vl (); size_t __attribute__((noinline)) get_vl (size_t *c) { size_t vl = c[0] + c[1]; return vl; }

[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #17 from Li Pan --- According to the V abi, looks like the asm code tries to save/restore the callee-saved registers when there is a call in function body. | Name| ABI Mnemonic | Meaning | Preserved across

[Bug c/114885] New: RISC-V: ICE of unrecog insn when graphite for both the c/c++ and fortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114885 Bug ID: 114885 Summary: RISC-V: ICE of unrecog insn when graphite for both the c/c++ and fortran Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c/115013] New: LRA: PR114810 fix result in ICE in the RISC-V Vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 Bug ID: 115013 Summary: LRA: PR114810 fix result in ICE in the RISC-V Vector Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3

  1   2   >