https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #5 from Kito Cheng ---
GCC 14 with enable checking will trigger that as well, thanks for remind that
detail, I forgot trunk will enable checking by default but release branch isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
--- Comment #2 from Kito Cheng ---
Hmmm, it's not well defined in the rvv intrinsic doc, but I suppose this should
at least work (compile-able) without crash, also it seems works fine on GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592
Kito Cheng changed:
What|Removed |Added
CC||cmuellner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116111
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995
--- Comment #3 from Kito Cheng ---
We have an internal qemu patch for adding an option to trigger this damm
behavior by default, and plan to upstream soon...let me ask our Qemu folk if I
can get the patch out first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #13 from Kito Cheng ---
FYI: PR for riscv-gnu-toolchain:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #12 from Kito Cheng ---
Qemu has provide two option to fill up all-one to agnostic policy:
rvv_ta_all_1s and rvv_ma_all_1s*, I guess we could enable that by default in
riscv-gnu-toolchain to discover more potential bugs.
* qemu-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725
--- Comment #2 from Kito Cheng ---
TU may not help for this case since we can't guarantee it's use v1 outside, I
mean the argument is passed via a1 (pointer) rather than passed via v1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115073
Bug ID: 115073
Summary: RISC-V: Gimple fold not honor
C[LT]Z_DEFINED_VALUE_AT_ZERO
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114747
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114885
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114172
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
--- Comment #4 from Kito Cheng ---
Fixed on trunk, but still ICE on 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #4 from Kito Cheng ---
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;
};
template using h = g::f;
template long k(d);
vbool16_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
--- Comment #1 from Kito Cheng ---
Thanks, forward and assigned this to our (SiFive) engineer :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113495
--- Comment #23 from Kito Cheng ---
> I am considering whether we should disable LICM for RISC-V by default if
> vector is enabled ?
That's will cause regression for other program, also may hurt those program not
vectorized but benefited from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #6 from Kito Cheng ---
> There needs to be a -Wabi warning for this too for the change between
> versions.
This bug only happened on trunk, and GCC 13 is OK, so I think it's not the
case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #20 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112109
--- Comment #1 from Kito Cheng ---
Just note:
I would like to introduce `-mstringop-strategy=`, `-mmemcpy-strategy=` and
-mmemset-strategy=` option to control the behavior like x86.
the possible option list from my mind is:
- auto: current st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
--- Comment #11 from Kito Cheng ---
It's not scope of auto vectorization, so I would suggest add something like
`-mstringop-strategy=*` or `-mmemcpy-strategy=*` (from x86) or
`-param=riscv-mops-memcpy-size-threshold=` (from aarch64).
Personally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112537
--- Comment #8 from Kito Cheng ---
That remind me we may need one option like something -mgeneral-regs-only in
aarch64 and also for target attribute.
BTW, clang has an generic option called -mno-implicit-float can did similar
thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
--- Comment #8 from Kito Cheng ---
Proposed fix:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636466.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112527
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #4 from Kito Cheng ---
Yeah, 3 major goal in LLVM is improving scheduling, partial spilling and
re-materialization, but none of those points are issue for RISC-V GCC :P
Ref:
https://docs.google.com/presentation/d/1BOYNYKe1T-u3Q5HXRr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #12 from Kito Cheng ---
oh, yeah, you are right, it already take a5 to splat, so it's right, and as you
said it must be VLMAX, unless it AVL prorogation for both splat and the
following vadd.vv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #10 from Kito Cheng ---
(In reply to JuzheZhong from comment #9)
> I have a draft patch to fix it:
>
> foo:
> ble a0,zero,.L5
> vsetvli a5,zero,e32,m1,ta,ma
> vid.v v2
> .L3:
> vsetvli a5,a0,e32,m1,ta,m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #8 from Kito Cheng ---
> Oh. I understand it now. I think it's a bug.
>
> And.. I just take a look at my internal LLVM...
> Also has same issue
>
> I think we need to adapt the Gimple IR here:
>
> _35 = .SELECT_VL (ivtmp_33,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #6 from Kito Cheng ---
The key is the splat of VLMAX instruction need move into loop body, but AVL
propagation should still able to do:
```
foo(int, int*, int*):
ble a0,zero,.L5
csrra5,vlenb
srlia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #5 from Kito Cheng ---
Assume:
VLEN = 128 and n = 5, *in is {0, 0, 0, 0, 0}
so VLMAX = 4 for e32m1
It can be run with vl = 4 for first iteration, and vl = 1 vl for second
iteration
But it could be something like that: vl = 3 for f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #2 from Kito Cheng ---
oh, but the root cause might be little bit deeper, not just the problem of
propagation or not propagation the AVL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #3 from Kito Cheng ---
Share some thought from my end: we've tried at least 3 different approach on
LLVM side before, and now we model that as "partial early clobber", we plan to
upstream this on LLVM side but just didn't get high e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433
--- Comment #1 from Kito Cheng ---
Give few more background why LLVM must do that way: LLVM can't allocate new
pseudo register during register allocation process, however spilling vector
register with specific length may require scratch register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926
--- Comment #2 from Kito Cheng ---
Forgot to mention, personally I love idea to simplify code gen, I could imagine
that's definitely an optimization for specific uarch :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
Bug ID: 111791
Summary: RISC-V: Strange loop vectorizaion on popcount function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #14 from Kito Cheng ---
Some info for generated files:
-
File blankcomment code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #13 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111412
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111372
--- Comment #5 from Kito Cheng ---
> Ok, but it's better to have configure option or something else just
> for toolchains that definitely do not use vector extension
I can understand that there would be such a demand in the embedded world, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110277
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110299
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111074
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109773
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
--- Comment #4 from Kito Cheng ---
I guess I skip too much detail here, the multilib for linux isn’t really honor
to the reause rule in the multilib config file for a while.
That just control how multilib build, e.g. build ilp32 with which arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
Kito Cheng changed:
What|Removed |Added
Version|og13 (devel/omp/gcc-13) |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037
Bug ID: 111037
Summary: RISC-V: Invalid vsetvli fusion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
Kito Cheng changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #4 from Kito Cheng ---
> OK, so TA is either merge or all-ones.
Yes, your understand is correct, just few more detail is that can be mixing
with either merge or all-ones.
e.g.
An 4 x i32 vector with mask 1 0 1 0
Op = | a | b |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #2 from Kito Cheng ---
And seems we already has such constraint for a while, not sure why GCC 13 did
that, I saw the status has changed to ASSIGNED, so I assume Vineet you are
already spending time on that, so I will just stop there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110696
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110448
Kito Cheng changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110448
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110188
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972
--- Comment #3 from Kito Cheng ---
We care but it's lower priority compare to other configuration, so create bug
to tracking here should be best solution for now :P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109974
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109743
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109748
--- Comment #1 from Kito Cheng ---
Is this also happened in GCC 13 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109617
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109272
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Summary|RISC-V: Multiple vsetvli|[13] RISC-V: Multiple
|f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Target Milestone|--- |13.2
Summary|internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2023-04-17
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #5 from Kito Cheng ---
Confirmed the the output is text file, it's just suffixed with .out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109479
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109461
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Kito Cheng changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
1 - 100 of 172 matches
Mail list logo
