https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113696
Li Pan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 L
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 3b32369f6
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.
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 || !loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195
--- Comment #3 from Li Pan ---
Testing a fix for possible regression.
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.
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: n
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: n
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
warranty;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
Li Pan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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 please
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110985
Li Pan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313
Li Pan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116202
--- Comment #2 from Li Pan ---
Confirmed, thanks and will take care of it soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116202
--- Comment #3 from Li Pan ---
(In reply to Li Pan from comment #2)
> Confirmed, thanks and will take care of it soon.
Just prepared a fix, and will send it out if no surprise from test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #3 from Li Pan ---
(In reply to Kito Cheng from comment #2)
> Hi Pan, could you take a look to see if it related to SAT_ADD?
Ack, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #5 from Li Pan ---
Reproduced from both qemu and hardware, let me take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #6 from Li Pan ---
(In reply to Andrew Pinski from comment #4)
> lb a1,0(a5) // load -40
> lui a0,%hi(.LC0)
> lui a4,%hi(c)
> addia5,a1,9 //a5 = -31
> sllia5,a5,48
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #7 from Li Pan ---
The backend take
rtx xmode_x = gen_lowpart (Xmode, x);
For the incoming op of .SAT_ADD, thus I think we should take lbu instead of lb
according to the ISA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #8 from Li Pan ---
(In reply to Li Pan from comment #7)
> The backend take
> rtx xmode_x = gen_lowpart (Xmode, x);
>
> For the incoming op of .SAT_ADD, thus I think we should take lbu instead of
> lb according to the ISA.
During u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116280
--- Comment #1 from Li Pan ---
Looks like some typos in md files, let me take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
--- Comment #11 from Li Pan ---
Thanks for suggestion, will move run test to
gcc/testsuite/gcc.c-torture/execute and only leave asm check under riscv.
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
Prior
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
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 RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
--- Comment #5 from Li Pan ---
Thanks kito, update the title for clarification.
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 L
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
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
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
Prio
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
Assigne
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #3 from Li Pan ---
Reproduced from my side too.
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;
>
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.
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 ());
}
../__RISC-V_INS
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 (!targetm.calls.function_value_regno_p
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 ...
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 l
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
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 L
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
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 = unsign
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
c
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;
}
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: norma
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
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013
Li Pan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387
--- Comment #2 from Li Pan ---
(In reply to Edwin Lu from comment #1)
> Bisected to r15-1081-ge14afbe2d1c being the first bad commit
Ack, thanks Edwin, will try to reproduce this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387
--- Comment #5 from Li Pan ---
Thanks all. I can reproduce this now.
Sorry I didn't run the test with glibc(only newlib), will take care of it ASAP.
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, 3
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
Seve
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&action=edit
Without this commit
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 riscv-autovec-preference=f
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.
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.
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 -mar
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 riscv-autovec-lmul=dy
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 arr[3
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
Pri
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
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
> DEF_INTERNAL_FLT_FL
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 DEF_EXT_LIB_FLOATN_NX_BU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
Li Pan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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.
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)
li
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: 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #9 from Li Pan ---
Before tracer
-
ENTRY
|
+---+
| B2 |
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
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.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=dbf8ab449417aa24669f6ccf50be8c17f
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 b
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 betwee
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 L
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.
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.
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
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
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;
> s
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
Compon
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110109
--- Comment #1 from Li Pan ---
GCC 13 doesn't have this issue.
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 L
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:
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:
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.
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
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.
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 borken
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 4a0a8dc1b88408222b88
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 L
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
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
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113393
Li Pan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109615
Li Pan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110265
Li Pan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 142 matches
Mail list logo
