https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #20 from Kito Cheng ---
Created attachment 47972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47972&action=edit
PR90811-ipa-increase-alignment.patch
Hi Jeff:
Updated patch attached, tested on riscv32/riscv64, this version ta
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
How to reproduce:
$ riscv64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
--- Comment #2 from Kito Cheng ---
I saw PR94027 before open this bug, it happened since same commit, I tested on
x86, x86_64, riscv32, riscv64, aarch64, arm, nds32le, mips, mips64, but only
riscv64 and arm fail on this testcase, and only ICE whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #2 from Kito Cheng ---
Hi Jim:
Not sure which way you will try first, maybe Monk or me can try to fix this by
add bunch of pattern of gpr_save/gpr_restore to model set/use register
correctly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95370
Kito Cheng changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
--- Comment #6 from Kito Cheng ---
Oh, seems like add uses is enough, exact pattern might add about ~200 line to
md file include RV32E/RV32/RV64 I guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
--- Comment #6 from Kito Cheng ---
Created attachment 48658
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48658&action=edit
i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch
Some optimization might made decision depend on the ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
Kito Cheng changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Kito Cheng --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|ASSIGNED
CC||kito at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96260
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96260
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2020-07-24
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
--- Comment #2 from Kito Cheng ---
It work on GCC 9, GCC will split that into two plain move instead of move from
a (subreg (parallel [(reg) (reg)])).
(insn 23 22 24 (set (reg:SI 83)
(reg:SI 10 a0)) "g++.target/riscv/pr96759.C":8:38 -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
--- Comment #3 from Kito Cheng ---
ICE after g:70cdb21e579191fe9f0f1d45e328908e59c0179e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
--- Comment #4 from Kito Cheng ---
ASAN related patches are seems need take more time than expect, I plan to fix
that this week, and I think ASAN is a new feature so that it won't back port to
GCC 10.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Target: riscv64-unknown-elf
Function with interrupt attribute use register without save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93304
--- Comment #1 from Kito Cheng ---
Created attachment 47669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47669&action=edit
pr93304-v1.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #17 from Kito Cheng ---
Created attachment 47920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47920&action=edit
update-local-align-pass.patch
Hi Jakub:
I got your point, and I agree with your point, estimate_stack_frame_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93995
--- Comment #3 from Kito Cheng ---
Ooop, confirmed, I am debugging now, thanks your report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #30 from Kito Cheng ---
After add --param max-inline-insns-size=1 to compile flags, x86, x86_64, rv32,
rv64, nds32 and arm are "Deleted redundant store" at dse1.
But mips, mips64 and aarch64 still not pass the scan testing since tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #31 from Kito Cheng ---
Maybe we could add --param max-inline-insns-size=1 to compile flag and add
mips* and aarch64 into xfail list to make every target happy for this test
case? and if some other target fail is cause by the CLEAR_RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93995
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441
--- Comment #2 from kito at gcc dot gnu.org ---
Author: kito
Date: Mon Aug 19 03:21:44 2019
New Revision: 274631
URL: https://gcc.gnu.org/viewcvs?rev=274631&root=gcc&view=rev
Log:
PR target/91441 - Turn off -fsanitize=kernel-ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441
kito at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #5 from Kito Cheng ---
Hi Zdenek:
Could you share more testcase? I've a patch is based on Jakub's one.
Thanks :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #7 from Kito Cheng ---
Hi Jakub:
> that doesn't mean paradoxical subregs can't appear there, just it will be
> less likely.
Does it mean paradoxical subregs will appear during intermediate result even
after reload, so for such spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #12 from Kito Cheng ---
Hi Zdenek:
I can reproduce for all new 3 testcases, it seems like cause by same issue,
thanks you provide more testcase for that!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #17 from Kito Cheng ---
Hi Jakub:
Thanks your patch, I've run with gcc testsuite and no new fails, and I am
ruining more gcc testsuite regression with different arch/abi combination for
that.
I am amazing that seems like RISC-V is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #26 from Kito Cheng ---
Author: kito
Date: Thu Sep 19 06:38:23 2019
New Revision: 275929
URL: https://gcc.gnu.org/viewcvs?rev=275929&root=gcc&view=rev
Log:
RISC-V: Fix bad insn splits with paradoxical subregs.
Shifting by more than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #21 from Kito Cheng ---
Author: kito
Date: Fri Sep 20 10:41:51 2019
New Revision: 275997
URL: https://gcc.gnu.org/viewcvs?rev=275997&root=gcc&view=rev
Log:
RISC-V: Fix more splitters accidentally calling gen_reg_rtx.
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
--- Comment #1 from Kito Cheng ---
I didn't see this testcase failed before, and I can't reproduce that on my work
environment, do you mind share your build environment, e.g. the version of gcc
or the distribution version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
--- Comment #3 from Kito Cheng ---
Thanks for providing environment info, I'll try that soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
Kito Cheng changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
--- Comment #12 from Kito Cheng ---
> This disables the CC_HAS_KASAN_GENERIC config of the kernel, making KASAN
> unavailable.
H, I checked with kernel source code, it only feed
-fsanitize=kernel-address during checking, but in fact it must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
Kito Cheng changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
Kito Cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
Kito Cheng changed:
What|Removed |Added
Priority|P4 |P3
--- Comment #5 from Kito Cheng ---
Patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|1
Last reconfirmed||2020-11-03
CC||kito at gcc dot gnu.org
--- Comment #3 from Kito Cheng ---
Confirmed, I got this issue few years ago when implementing large code model on
GCC, but I never upstream or open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #16 from Kito Cheng ---
> Or maybe we make the choice of zero-extend or sign-extend depend on the mode,
> and use zero-extend for smaller than SImode and sign-extend for SImode and
> larger.
Maybe depend on LOAD_EXTEND_OP?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
--- Comment #7 from Kito Cheng ---
Committed fix into trunk, wait one week to commit to gcc 10 branh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #25 from Kito Cheng ---
Seem like you have add code to gcc/optabs.h and gcc/optabs.c, however those
functions are RISC-V specific, so I would suggest you put in riscv.c and
riscv-protos.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #37 from Kito Cheng ---
Maybe we could add a parameter to indicate the type of memory access,
plain_mem, zext_mem or sext_mem for pass_shorten_memrefs::get_si_mem_base_reg.
e.g.
for (int i = 0; i < 2; i++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||kito at gcc dot gnu.org
--- Comment #2 from Kito Cheng ---
The script has test with python2 and python3, but seems like require python as
essential for building RISC-V is inappropriate, I'll send patch later to made
this become optional.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #55 from Kito Cheng ---
Hi jiawei:
Thanks for the data, the performance changing for coremark-pro seems
interesting, could you find which part generate different code after the patch?
And I am curious what the platform you used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #58 from Kito Cheng ---
Hi jiawei:
I would suggest you just using inst count rather than cycle or time for
measuring benchmark if you using qemu, since qemu is functional simulator not
cycle accurate neither nearly-cycle accurate sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596
--- Comment #2 from Kito Cheng ---
Few years ago, Monk and me has write a very detailed cost model for nds32 port,
that way might able to fix the issue and further optimized for the code size
and performance, but...it need lots time to fine tune
gcc dot gnu.org |kito at gcc dot gnu.org
--- Comment #1 from Kito Cheng ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743
--- Comment #2 from Kito Cheng ---
ICE after g:6fbec038f7a7ddf29f074943611b53210d17c40c, hmmm...interesting...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743
--- Comment #3 from Kito Cheng ---
Seems like g:3e60ddeb8220ed388819bb3f14e8caa9309fd3c2 is the real root cause
Assignee: kito at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
CC: sebastian.hu...@embedded-brains.de, wilson at gcc dot
gnu.org
Target Milestone: ---
Target: riscv32-rtems
Sebastian has reported multilib generation for RTEM is broken after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: riscv64-unknown-elf
Flags: -Ofast -fno-gcse -fmodulo-sched -freorder-blocks-and-partition
-fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #13 from Kito Cheng ---
Patch posted before, but seems like not everybody agree:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603049.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108764
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
Kito Cheng changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
--- Comment #4 from Kito Cheng ---
Thanks your info, that cause by the default ISA spec version bump issue,
binutils 2.38 and GCC 11.* using different default ISA spec cause this issue,
I've push a patch to GCC 11 branch [1] for this issue, coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957
Kito Cheng changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
Kito Cheng changed:
What|Removed |Added
Last reconfirmed||2022-03-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
--- Comment #10 from Kito Cheng ---
I plan to fix that in next few day for trunk and backport to GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
--- Comment #13 from Kito Cheng ---
Hi rvalue:
Pushed the fix to trunk and GCC 11 branch for fixing both arch-canonicalize and
multilib-generator script.
Tested GCC 11/trunk with --with-isa-spec=2.2/20191213.
Could you try that to make sure t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106338
--- Comment #6 from Kito Cheng ---
My understanding is static chain is sort of compiler internal implementation,
any register could be picked if that is not used for passing argument, so I
would also prefer keep that out psABI spec for now.
An
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Target: riscv
Command:
$ riscv64-unknown-elf-gcc foo.c -o - -S -O3 -march=rv64imafdc_zbb_zbs
```c
int foo(int rs1, int rs2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106532
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #4 from Kito Cheng ---
> It uses X iterator here instead of GPR, hmmm ...
I think that because we have w-variant before, so use X rather than GPR here,
but apparently we should revise this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #5 from Kito Cheng ---
bset generated after change X to GPR for most zbs pattern:
```
foo:
bseta1,x0,a1
andna0,a0,a1
sext.w a0,a0
ret
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219
--- Comment #3 from Kito Cheng ---
Patch posted to mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589225.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219
--- Comment #5 from Kito Cheng ---
I plan back port this fix to GCC 11 branch too, and will close this bug after
back port.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957
--- Comment #3 from Kito Cheng ---
Wait another week for make sure stable and backport to gcc-11 and gcc-10
branch.
|NEW
CC||kito at gcc dot gnu.org
Last reconfirmed||2021-12-02
--- Comment #1 from Kito Cheng ---
Confirmed, but I suspect it's binutils bugs, I've forward bug to Nelson Chu
(RISC-V binutils maintainer)
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
Target Milestone: ---
ranger taking too deep recursive checking on program with lots of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
--- Comment #2 from Kito Cheng ---
Oh, apologize for misleading, it should fixed via pr103231 rather than
pr103254.
it work after g:5deacf6058d1bc7261a75c9fd1f116c4442e9e60, no new file, but it's
not trivial backport-able.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
--- Comment #4 from Kito Cheng ---
Hi Andrew:
Thanks for your quick response! the patch is work to me for the testcase,
but...I got seg fault when I built x86 GCC.
Here is a reduced case from gcov, and this testcase also take longer
compilatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
--- Comment #6 from Kito Cheng ---
Reported testcase is OK and I test that patch on riscv64-elf and riscv64-linux
with full gcc testsuite run, both are no regression.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
How to reproduce:
g++ x.cpp
Testcase:
```
#include
struct X {
union {
uint8_t r8[8];
uint32_t r32[2];
};
};
struct ctx {
X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
Kito Cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
gcc dot gnu.org |kito at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-11-01
--- Comment #1 from Kito Cheng ---
Confirmed, thanks for report this issue :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
Kito Cheng changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 218 matches
Mail list logo
