[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
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?
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
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.
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-05 Ever confirmed|0 |1 --- Comment #4 from Kito Cheng --- I can reproduce that on Ubuntu 20.04 + gcc 9.3, it turns out the length is out of range with `signed HOST_WIDE_INT`, but after few more investigate the upper function is feed `unsigned HOST_WIDE_INT` (emit_block_move_via_pattern), and I guess here is some code gen change for alloca, so it will ICE on Ubuntu 20.04 + gcc 9.3, but not ICE on Ubuntu 18.04 + gcc 7.5. Thanks Sinan, I've write second version of the patch, it's kind of very different than your patch, but I think you deserved that credit, so I'll list you as first author for that patch :)
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 Kito Cheng changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #6 from Kito Cheng --- I would prefer keep this open until merged into master, gcc-10 and gcc-9 branch.
[Bug sanitizer/96307] [10 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458
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 work with -fasan-shadow-offset=, and it does actually, what do you think about fix that on kernel side? diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index fba9909e31b7..9a2484132b2d 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -13,7 +13,7 @@ config HAVE_ARCH_KASAN_VMALLOC bool config CC_HAS_KASAN_GENERIC - def_bool $(cc-option, -fsanitize=kernel-address) + def_bool $(cc-option, -fsanitize=kernel-address -fasan-shadow-offset=0x1) config CC_HAS_KASAN_SW_TAGS def_bool $(cc-option, -fsanitize=kernel-hwaddress) > Also, the warning text doesn't make sense: > > $ gcc -fsanitize=kernel-address -S -xc /dev/null -o /dev/null > cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not > supported without ‘-fasan-shadow-offset=’ for this target That's my fault I didn't update the error message there, that error message was introduced when fixing PR96260, but during fix this PR. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96260
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314 Kito Cheng changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Kito Cheng --- Committed fix into trunk, gcc-10 and gcc-9
[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since r11-7757-gfc9c4e5fc50c7fcbd27d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Kito Cheng --- Hi Zdenek: Confirmed, and has fix patch, it's trivial fix, so I'll commit the fix after test. I believe its cause by this patch: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d9f0ade001533c9544bf2153b6baa8844ec0bee4 Hi Martin: Thanks for the info :)
[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy() since g:d9f0ade001533c9544bf2153b6baa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Hi Martin, Zdenek: Thanks you guys!
[Bug bootstrap/97409] riscv cross toolchain build fails
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 from Kito Cheng --- Could you provide more detail, e.g. what configure option you are using? and the build steps/command you use? Thanks :)
[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294
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 Status|NEW |ASSIGNED --- Comment #5 from Kito Cheng --- Committed to trunk, will set as resolve after commit to gcc 10 branch :)
[Bug sanitizer/96307] [10/11 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307 Kito Cheng changed: What|Removed |Added Priority|P4 |P3 --- Comment #5 from Kito Cheng --- Patch posted, waiting for review: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555482.html
[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Fixed on both trunk and gcc 10.
[Bug target/97682] Miscompiled tail call with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |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 source that, and I have no chance to access it now...anyway, our guys is fixing that now, thanks your report!
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 from Kito Cheng --- > Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c Seems like shorten_memrefs pass didn't handle zero_extend and sign_extend with memory. You can take a look into riscv-shorten-memrefs.c:pass_shorten_memrefs::analyze and add logic to handle zero_extend and sign_extend. > With one instruction less, the patched one seems right and even faster to me. > However we still need a test on sign extend and check performance shorten_memrefs is optimize for size, the idea is transform several load instructions with large immediate to a load immediate instruction and load instructions with small immediate, to use C-extensions instruction as possible. so the instruction count seems increased, but the code size is smaller.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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?
[Bug sanitizer/96307] [10/11 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458
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.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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++)
{
rtx mem = XEXP (pat, i);
rtx addr;
mem_access_type_t type;
if (get_si_mem_base_reg (mem, &addr, &type))
{
HOST_WIDE_INT regno = REGNO (XEXP (addr, 0));
/* Do not transform store zero as these cannot be compressed. */
if (i == 0)
{
if (XEXP (pat, 1) == CONST0_RTX (GET_MODE (XEXP (pat, 1
continue;
}
if (m->get_or_insert (regno) > 3)
{
addr
= targetm.legitimize_address (addr, addr, GET_MODE (mem));
switch (type)
{
case plain_mem:
XEXP (pat, i) = replace_equiv_address (mem, addr);
break;
case zext_mem:
...
break;
case sext_mem:
...
break;
}
df_insn_rescan (insn);
}
}
[Bug target/97682] Miscompiled tail call with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Fixed on trunk and backport to gcc 9 and gcc 10.
[Bug target/98152] [11 regression] /usr/bin/env: 'python': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED CC||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.
[Bug target/98152] [11 regression] /usr/bin/env: 'python': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Kito Cheng --- I just made python as optional, the functional is not changed, just could be build one more redundant multi-lib.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 the performance data?
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 simulator, so the performance number is coming from your native host (x86_64) cpu, and it also might sensitive on your host loading. or maybe you could try gem5 for that? Thanks your helping benchmark that :)
[Bug target/98596] registers not reused on RISC-V
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 and run benchmark again and again, so not sure when it can done. https://github.com/gcc-mirror/gcc/blob/master/gcc/config/nds32/nds32-cost.c
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- Confirmed.
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 --- Comment #2 from Kito Cheng --- ICE after g:6fbec038f7a7ddf29f074943611b53210d17c40c, hmmm...interesting...
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 --- Comment #3 from Kito Cheng --- Seems like g:3e60ddeb8220ed388819bb3f14e8caa9309fd3c2 is the real root cause
[Bug target/98878] New: Incorrect multilib list for riscv*-rtems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878 Bug ID: 98878 Summary: Incorrect multilib list for riscv*-rtems Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target 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 g:a5ad5d5c478ee7bebf057161bb8715ee7d286875. GCC configure: --with-arch=rv32gc --with-abi=ilp32 --target=riscv32-rtems. Before this commit g:a5ad5d5c478ee7bebf057161bb8715ee7d286875: ./gcc/xgcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32imafd/ilp32d;@march=rv32imafd@mabi=ilp32d <-- HERE rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imafd/lp64d;@march=rv64imafd@mabi=lp64d rv64imafd/lp64d/medany;@march=rv64imafd@mabi=lp64d@mcmodel=medany rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imac/lp64/medany;@march=rv64imac@mabi=lp64@mcmodel=medany rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d rv64imafdc/lp64d/medany;@march=rv64imafdc@mabi=lp64d@mcmodel=medany ./gcc/xgcc -print-multi-directory -march=rv32imafd -mabi=ilp32d rv32imafd/ilp32d After this commit g:a5ad5d5c478ee7bebf057161bb8715ee7d286875: ./gcc/xgcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imafd/lp64d;@march=rv64imafd@mabi=lp64d rv64imafd/lp64d/medany;@march=rv64imafd@mabi=lp64d@mcmodel=medany rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imac/lp64/medany;@march=rv64imac@mabi=lp64@mcmodel=medany rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d rv64imafdc/lp64d/medany;@march=rv64imafdc@mabi=lp64d@mcmodel=medany ./gcc/xgcc -print-multi-directory -march=rv32imafd -mabi=ilp32d rv32imafd/ilp32d --- The difference is rv32imafd/ilp32d is disappeared from the output of -print-multi-directory, the gcc think that could reuse the default library, but it's not true, but seems like -print-multi-directory is doing right here.
[Bug target/98743] ICE in convert_move, at expr.c:220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98743 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Fixed on trunk.
[Bug sanitizer/96307] [10 Regression] ICE in sanopt on riscv64 since r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Kito Cheng --- Fixed on 10 and trunk.
[Bug target/98878] Incorrect multilib list for riscv*-rtems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Kito Cheng --- Fixed on trunk.
[Bug target/98981] gcc-10.2 for RISC-V has extraneous register moves
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 from Kito Cheng ---
Here is a quick patch for fix part of this issue, it seems like because our
cost model is inprecise, but I guess I need run benchmark to make sure the
performance and code size didn't get any regression.
find_max_i32:
lui a4,%hi(.LANCHOR0)
addia4,a4,%lo(.LANCHOR0)
addia3,a4,1024
addia6,a4,400
li a0,0
.L3:
lw a5,0(a4)
lw a2,0(a3)
addia4,a4,4
addia3,a3,4
addwa1,a5,a2
addwa5,a5,a2
bge a1,a0,.L2
mv a5,a0
.L2:
sext.w a0,a5
bne a4,a6,.L3
ret
Patch:
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index d489717b2a5..b8c9f7200ce 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -1879,6 +1879,15 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBUTE_UN
}
/* Fall through. */
case SIGN_EXTEND:
+ if (TARGET_64BIT && !REG_P (XEXP (x, 0)))
+ {
+ int code = GET_CODE (XEXP (x, 0));
+ if (code == PLUS || code == MINUS || code == NEG || code == MULT)
+ {
+ *total = COSTS_N_INSNS (1);
+ return true;
+ }
+ }
*total = riscv_extend_cost (XEXP (x, 0), GET_CODE (x) == ZERO_EXTEND);
return false;
[Bug rtl-optimization/100647] New: ICE during sms pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647
Bug ID: 100647
Summary: ICE during sms pass
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
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-tree-dce -march=rv64gc -mabi=lp64
Testcase:
char c;
char *d;
char *e();
char *f(char *h) {
int a = *h;
return *h == 7 ? h : h + a;
}
char i() {
char *g, *b;
g = e();
for (; g; b = f(b))
if (c)
*d = 0;
return 0;
}
ICE Message:
during RTL pass: sms
sms.crash.c: In function 'i':
sms.crash.c:15:1: internal compiler error: in
cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4651
15 | }
| ^
0x82a8a8 cfg_layout_redirect_edge_and_branch_force
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgrtl.c:4651
0x8102d3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfghooks.c:490
0x810de5 make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfghooks.c:903
0x81a88d merge_latch_edges
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:780
0x81a88d disambiguate_multiple_latches
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:831
0x81a88d disambiguate_loops_with_multiple_latches()
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:844
0xb35484 apply_loop_flags
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/loop-init.c:55
0xb3605c loop_optimizer_init(unsigned int)
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/loop-init.c:124
0x15b8039 sms_schedule
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/modulo-sched.c:1362
0x15bac1f execute
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/modulo-sched.c:3359
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
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
[Bug target/108764] [RISCV] Cost model for RVB is too aggressive
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 from Kito Cheng --- > I think one solution is to change the cost model of such complex instructions > to the sum of the cost for each part. E.g. > cost for shNadd = COSTS_N_INSNS (SINGLE_SHIFT_COST) + COSTS_N_INSNS (1) # > cost of addition Some RISC-V core implementation did has one cycle for shNadd operation as I know, but I know it's not true for every implementation. Anyway, it's really uarch dependent, so I would prefer keep as it for now, and then extend the cost model function to easier handle different uarch (-mtune) when GCC 14 is open.
[Bug target/108339] [11/10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Backported to GCC 10 branch.
[Bug target/108185] [RISC-V] Sub-optimal code-gen for vsetvli: redundant stack store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Resolved by Pan's patch :)
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
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 from Kito Cheng --- Do you mind give few more version info for binutils and configuration info for gcc? You can obtain those info by following two commands: $ gcc -v $ as --version Thanks
[Bug target/104219] [12 regression] riscv64 compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Kito Cheng --- Committed to trunk and backported to GCC 11 branch
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
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, could you try this patch? thanks. See more detail for the full story about ISA spec: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9871d39f752bc9c114ed694662a519d04896f491
[Bug target/102957] [riscv64] ICE on bogus -march value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Kito Cheng --- Backported to GCC 11.
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 Kito Cheng changed: What|Removed |Added Last reconfirmed||2022-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #8 from Kito Cheng --- Hi rvalue: I pushed couple fixes to gcc 11 release branch, mostly back from trunk and a fix for setting right isa spec value: g:f41871dfdbd9d0c3368c0bc32d879fd5485e7abb I expect that could fix that issue, could you try again with top of gcc 11 branch? Thanks!
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
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.
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
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 that work to you?
[Bug target/106338] RISC-V static-chain register may be clobbered by PLT stubs
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. And just record info for myself: x86-64 ABI has document function's static chain pointer in their ABI https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex#L701
[Bug target/106585] New: RISC-V: Mis-optimized code gen for zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
Bug ID: 106585
Summary: RISC-V: Mis-optimized code gen for zbs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
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) {
return (rs1 & ~(1<
[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit
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 from Kito Cheng --- HI Andrew: That's would be great if you can back port to GCC 12 branch, and thanks for your quick fix :)
[Bug target/106585] RISC-V: Mis-optimized code gen for zbs
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.
[Bug target/106585] RISC-V: Mis-optimized code gen for zbs
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 ```
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
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 from Kito Cheng ---
We are hitting this issue on RISC-V, and got some complain from linux kernel
developers, but in different form as the original report, we found cold
function or any function is marked as cold by `-fguess-branch-probability` are
all not honor to the -falign-functions=N setting, that become problem on some
linux kernel feature since they want to control the minimal alignment to make
sure they can atomically update the instruction which require align to 4 byte.
However current GCC behavior can't guarantee that even -falign-functions=4 is
given, there is 3 option in my mind:
1. Fix -falign-functions=N, let it work as expect on -Os and all cold functions
2. Force align to 4 byte if -fpatchable-function-entry is given, that's should
be doable by adjust RISC-V's FUNCTION_BOUNDARY
3. Adjust RISC-V's FUNCTION_BOUNDARY to let it honor to -falign-functions=N
4. Adding a -malign-functions=N...Okay, I know that suck idea, x86 already
deprecated that.
But I think ideally this should fixed by 1 option if possible.
Testcase from RISC-V kernel guy:
```
/* { dg-do compile } */
/* { dg-options "-march=rv64gc -mabi=lp64d -O1 -falign-functions=128" } */
/* { dg-final { scan-assembler-times ".align 7" 2 } } */
// Using 128 byte align rather than 4 byte align since it easier to observe.
__attribute__((__cold__)) void a() {} // This function isn't align to 128 byte
void b() {} // This function align to 128 byte.
```
Proposed fix:
```
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 49d5cda122f..6f8ed85fea9 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1907,8 +1907,7 @@ assemble_start_function (tree decl, const char *fnname)
Note that we still need to align to DECL_ALIGN, as above,
because ASM_OUTPUT_MAX_SKIP_ALIGN might not do any alignment at all. */
if (! DECL_USER_ALIGN (decl)
- && align_functions.levels[0].log > align
- && optimize_function_for_speed_p (cfun))
+ && align_functions.levels[0].log > align)
{
#ifdef ASM_OUTPUT_MAX_SKIP_ALIGN
int align_log = align_functions.levels[0].log;
```
[Bug target/104219] riscv64-elf cross compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-01-25 Ever confirmed|0 |1 --- Comment #2 from Kito Cheng --- That's definitely cause by the ISA spec bumping, I tested with binutils trunk but didn't test with 2.37. Let me fix that to make sure GCC work with older binutils release.
[Bug target/104219] riscv64-elf cross compiler build fails
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
[Bug target/104219] [12 regression] riscv64 compiler build fails
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.
[Bug target/102957] [riscv64] ICE on bogus -march value
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.
[Bug target/103525] [RISCV] wrong function entry with -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103525 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |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)
[Bug tree-optimization/103603] New: [11 Regression] stack overflow on ranger for huge program, but OK for legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
Bug ID: 103603
Summary: [11 Regression] stack overflow on ranger for huge
program, but OK for legacy
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: 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 expression,
but fixed on trunk via pr103254, however the patch-set is not easy to backport
to GCC 11 since gimple-range-path.cc isn't exist at GCC 11.
Testcase:
```
#define STMT \
t += 1; \
t *= 2; \
t -= 1; \
t &= 0xfff00fff; \
t ^= 0x14022; \
t %= 0xff3; \
t += 6; \
t *= 10; \
#define STMT2 STMT STMT
#define STMT4 STMT2 STMT2
#define STMT8 STMT4 STMT4
#define STMT16 STMT8 STMT8
#define STMT32 STMT16 STMT16
#define STMT64 STMT32 STMT32
#define STMT128 STMT64 STMT64
#define STMT256 STMT128 STMT128
int foo(int init) {
int t = init,i,iter;
for(iter=0; iter < 2; ++iter) {
STMT256 STMT256 STMT256
}
return t;
}
```
How to reproduce:
$ gcc-11 xred.c -O2 # OK with --param=evrp-mode=legacy
gcc-11: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0141550f in gimple_ranger::range_of_range_op(irange&, gimple*) ()
(gdb) bt
#0 0x0141550f in gimple_ranger::range_of_range_op(irange&, gimple*) ()
#1 0x01417b9b in gimple_ranger::calc_stmt(irange&, gimple*,
tree_node*) ()
#2 0x01418152 in gimple_ranger::range_of_stmt(irange&, gimple*,
tree_node*) ()
#3 0x01413ce1 in gimple_ranger::range_of_expr(irange&, tree_node*,
gimple*) ()
#4 0x01415604 in gimple_ranger::range_of_range_op(irange&, gimple*) ()
#5 0x01417b9b in gimple_ranger::calc_stmt(irange&, gimple*,
tree_node*) ()
#6 0x01418152 in gimple_ranger::range_of_stmt(irange&, gimple*,
tree_node*) ()
#7 0x01413ce1 in gimple_ranger::range_of_expr(irange&, tree_node*,
gimple*) ()
#8 0x01415604 in gimple_ranger::range_of_range_op(irange&, gimple*) ()
#9 0x01417b9b in gimple_ranger::calc_stmt(irange&, gimple*,
tree_node*) ()
Note:
GCC 11 with--param=evrp-mode=legacy and GCC-12 (after
g:d1c1919ef8a18eea9d5c1741f8c9adaabf5571f2) are work without stack overflow
even more statement like that:
```
#define STMT \
t += 1; \
t *= 2; \
t -= 1; \
t &= 0xfff00fff; \
t ^= 0x14022; \
t %= 0xff3; \
t += 6; \
t *= 10; \
#define STMT2 STMT STMT
#define STMT4 STMT2 STMT2
#define STMT8 STMT4 STMT4
#define STMT16 STMT8 STMT8
#define STMT32 STMT16 STMT16
#define STMT64 STMT32 STMT32
#define STMT128 STMT64 STMT64
#define STMT256 STMT128 STMT128
int foo(int init) {
int t = init,i,iter;
for(iter=0; iter < 2; ++iter) {
STMT256 STMT256 STMT256 STMT256 STMT256 STMT256 STMT256 STMT256 STMT256
STMT256 STMT256
}
return t;
}
```
[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy
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.
[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy
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
compilation time than expect (>15s to compile and ICE, but ~0.01s w/o patch):
```
struct gcov_ctr_info {
int values;
};
struct gcov_fn_info {
struct gcov_ctr_info ctrs[1];
};
struct gcov_info {
struct gcov_fn_info **functions;
};
void __gcov_dump_one() {
{
struct gcov_info gi_ptr;
int gi_ptr_1;
struct gcov_info gi_ptr_0;
int run_max ;
for (; ; )
for (unsigned f_ix ; gi_ptr_1; f_ix) {
struct gcov_ctr_info *cinfo = gi_ptr.functions[0];
int cinfo_0;
for (unsigned i ; cinfo_0; i) {
run_max < &cinfo;
run_max = cinfo->values;
}
}
for (; &gi_ptr; )
;
}
}
```
Backtrace:
during GIMPLE pass: evrp
gcov.c:28:1: internal compiler error: Segmentation fault
28 | }
| ^
0xba283f crash_signal
../../../riscv-gnu-toolchain/riscv-gcc/gcc/toplev.c:327
0x1488666 vec::quick_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1023
0x1488666 vec::quick_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1875
0x1488666 vec::safe_push(tree_node* const&)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/vec.h:1888
0x1488666 gimple_ranger::prefill_stmt_dependencies(tree_node*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:1177
0x14892de gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:1089
0x1482b45 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-range.cc:982
0xe46670 range_query::value_of_expr(tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/value-query.cc:86
0x14960e0 hybrid_folder::value_of_expr(tree_node*, gimple*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-ssa-evrp.c:235
0xd1575b substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/tree-ssa-propagate.c:1072
0x145cb34 dom_walker::walk(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/domwalk.c:309
0xd14d85 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../../riscv-gnu-toolchain/riscv-gcc/gcc/tree-ssa-propagate.c:1283
0x1495c34 execute_early_vrp
../../../riscv-gnu-toolchain/riscv-gcc/gcc/gimple-ssa-evrp.c:349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy
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.
[Bug c++/102538] New: Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538
Bug ID: 102538
Summary: Wrong narrowing conversion checking for initializer
with union
Product: gcc
Version: 12.0
Status: UNCONFIRMED
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:
g++ x.cpp
Testcase:
```
#include
struct X {
union {
uint8_t r8[8];
uint32_t r32[2];
};
};
struct ctx {
X v[1];
};
ctx x = {
{
{.r32 = {5,0x3}},
}
};
```
Message:
x.cpp:19:1: error: narrowing conversion of '209715' from 'int' to 'uint8_t'
{aka 'unsigned char'} [-Wnarrowing]
19 | };
| ^
Work with GCC 11.1 but not work with GCC 11.2 and trunk
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Fixed are committed to both trunk and gcc-11 branch now :)
[Bug target/102957] [riscv64] ICE on bogus -march value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102957 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at 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 :)
[Bug target/108185] [RISC-V]RVV assemble not set vsetvli correct.
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 from Kito Cheng --- It seems right to me? ``` $ riscv64-unknown-elf-gcc pr108185.c -march=rv64gcv -mabi=lp64d -O3 -S -o - .file "pr108185.c" .option nopic .attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0" .attribute unaligned_access, 0 .attribute stack_align, 16 .text .align 1 .globl foo5_3 .type foo5_3, @function foo5_3: csrrt0,vlenb sllit1,t0,1 csrra5,vlenb sub sp,sp,t1 sllia3,a5,1 add a3,a3,sp vl1re8.vv25,0(a0) # Load value from *(vint8m1_t*)in sub a5,a3,a5 vs1r.v v25,0(a1) # Store value to *(vint8m1_t*)out vs1r.v v25,0(a5) # Store value to stack, although it's unused. addia4,a1,800 csrrt0,vlenb sllit1,t0,1 vsetvli a5,zero,e8,m1,ta,ma # Right vsetvli for vsm.v vsm.v v25,0(a4) add sp,sp,t1 jr ra .size foo5_3, .-foo5_3 .ident "GCC: (g44b22ab81cf) 13.0.0 20221229 (experimental)" ```
[Bug target/108185] [RISC-V] Sub-optimal code-gen for vsetvli: redundant stack store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-03 --- Comment #4 from Kito Cheng --- So it's about the code gen quality instead of correctness, let me update the title.
[Bug target/105733] riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-26 --- Comment #1 from Kito Cheng --- Confirmed, Thanks for reporting this!
[Bug testsuite/106149] [13 regression] g++.dg/warn/Warray-bounds-16.C had bogus errors after r13-1366-g1eef21ccfa5988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106149 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- Revert the commit for now...and I am figure out how to resolve this: lp64 target will have 2 warnings: 22:7: warning: array subscript 0 is outside array bounds of 'void [0]' [-Warray-bounds] 19:51: note: object of size 0 allocated by 'operator new []' 22:7: warning: 'void* __builtin_memset(void*, int, long unsigned int)' offset [0, 3] is out of the bounds [0, 0] [-Warray-bounds] ilp32 target will have only 1 warning: 22:7: warning: array subscript 0 is outside array bounds of 'void [0]' [-Warray-bounds] 19:51: note: object of size 0 allocated by 'operator new []'
[Bug target/101275] [RISCV] Document the machine constraint 'S' and make it non-internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101275 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- I am happy to add it to document, here it the patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574318.html
[Bug target/101275] [RISCV] Document the machine constraint 'S' and make it non-internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101275 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Kito Cheng --- Change committed to trunk
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Kito Cheng --- Implemented on trunk now :)
[Bug target/106530] RISCV documentation for -march= is very lacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kito Cheng --- g:19260a04ba6f75b1fae52afab50dcb43d44eb259 and g:5a22bb250d8f4ad239e12fea9828c18a0aa23e38 should address this issue :)
[Bug target/110748] RISC-V: optimize store of DF 0.0
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 from Kito Cheng ---
hmmm, weird, GCC 12 did well but something wrong after GCC 13?
https://godbolt.org/z/ToM1qTxrq
void zd(double *d) { *d = 0.0; }
void zf(float *f) { *f = 0.0; }
GCC 12:
zd:
sd zero,0(a0)
ret
zf:
sw zero,0(a0)
ret
GCC 13:
zd:
fmv.d.x fa5,zero
fsd fa5,0(a0)
ret
zf:
fmv.s.x fa5,zero
fsw fa5,0(a0)
ret
[Bug target/110748] RISC-V: optimize store of DF 0.0
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 :)
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
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 | c | d | Mask = | 1 | 0 | 1 | 0 | the result could be: | a | b | c | d | | a | all-1 | c | d | | a | all-1 | c | all-1 | | a | all-1 | c | d | > Not sure how you can use MA at the moment since you specify an existing > operand in your target hook. As far as > I can see there's no value the target hook can provide that matches any of the implementation semantics? That's the key point - we don't know how to return an undefined value there, we have intrinsic can generate undefined value, but it seems impossible to generate that within the hook.
[Bug target/110812] Missing TARGET_OPTION_SAVE/RESTORE on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED CC||kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- Ooops, I thought those target hook should implement when we have implement target attribute, anyway thanks for the hint!
[Bug target/111037] New: RISC-V: Invalid vsetvli fusion
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
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
CC: juzhe.zhong at rivai dot ai
Target Milestone: ---
Target: riscv64
Reduced case:
```
#include
void foo(_Float16 y, int64_t *i64p)
{
vint64m1_t vx =__riscv_vle64_v_i64m1 (i64p, 1);
vx = __riscv_vadd_vv_i64m1 (vx, vx, 1);
vfloat16m1_t vy =__riscv_vfmv_s_f_f16m1 (y, 1);
asm volatile ("# use %0 %1" : : "vr"(vx), "vr" (vy));
}
```
Command to reproduce:
$ riscv64-unknown-elf-gcc -O3 -march=rv64gczve64f_zvfh
foo:
vsetivlizero,1,e64,m1,ta,ma
vle64.v v1,0(a0)
vfmv.s.fv2,fa0 # Will raise illegal instruction here, because
we don't have F64 for vector
vadd.vv v1,v1,v1
ret
[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns
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||kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- One major issue around multilib for linux is we only encode abi to the path, so it hard to extend that like baremetal toolchain.
[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns
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, and we will find matched ABI, but why we did that? The reason is simplify the reuse rule, RISC-V has huge number of extension now, so enumeration the possible combination are almost impossible. But why it can’t use same scheme as baremetal? Okay, that’s because we encode the abi in the path only, unlike baremetal we have encode both abi and arch, it kinda of de facto ABI in linux/glibc, also it not make too much sense to having too much different multilib within a (RISC-V) linux system.
[Bug target/109725] [14 Regression] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_print_operand, at config/riscv/riscv.cc:4430
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 from Kito Cheng --- Ok for back port :)
[Bug target/109773] RISC-V: ICE when build RVV Intrinsic in Both GCC 13 && GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109773 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Kito Cheng --- Fixed on upstream for a while.
[Bug target/110560] internal compiler error: in extract_constrain_insn_cached, at recog.cc:2704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Kito Cheng --- Should fixed now
[Bug target/111074] RISC-V: segmentation fault during RTL pass: vsetvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111074 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- Fixed
[Bug target/111037] RISC-V: Invalid vsetvli fusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111037 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Kito Cheng --- Fixed
[Bug target/110299] 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 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Kito Cheng --- Fixed on trunk
[Bug target/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 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Kito Cheng --- Fixed on trunk
[Bug target/111372] libgcc: RISCV C++ exception handling stack usage grew in 13.1
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 that's not critical issue, so this won't get high priority to most RISC-V GCC developer, it would be appreciate if you could send a patch for that.
[Bug target/111412] RISC-V:ICE in phase 6 of vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111412 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- fixed
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
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 from Kito Cheng --- I guess we may need something like this g:703417a0 for those generator for md file?
[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111664 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-10-03 --- Comment #3 from Kito Cheng --- Proposed fix, and verified with mawk on my machine :) https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #14 from Kito Cheng --- Some info for generated files: - File blankcomment code - insn-output.cc 3532 350291631721 insn-emit.cc 37288 402401161790 insn-recog.cc 44203 23 428130 insn-attrtab.cc 1014 30 169934 gimple-match-2.cc 77 2 49303 gimple-match-9.cc 29 2 33073 insn-extract.cc 241 8 28934 gimple-match-1.cc105 2 25578 gimple-match-8.cc114 2 24348 options.cc 325 1 24175 insn-opinit.cc12 6 20156 generic-match-9.cc55 2 19080 gimple-match-3.cc 98 2 17433 gimple-match-7.cc108 2 17105 gimple-match-10.cc 129 2 16888 gimple-match-6.cc115 2 16836 gimple-match-4.cc 97 2 16830 gimple-match-5.cc 99 2 16377 generic-match-3.cc57 2 16138 options-save.cc 1037 19 15121 generic-match-4.cc70 2 14095 gtype-desc.cc679 30 12597 insn-automata.cc 73 11 11735 generic-match-2.cc60 2 11543 generic-match-1.cc56 2 11504 generic-match-7.cc66 2 10238 generic-match-5.cc71 2 10231 generic-match-10.cc 66 2 9860 generic-match-6.cc61 2 9853 generic-match-8.cc53 2 9651 insn-modes.cc750410 7655 min-insn-modes.cc 9 2 2280 gengtype-lex.cc 398424 2126 insn-preds.cc146 32 1515 insn-dfatab.cc31 3 1230 insn-latencytab.cc26 3 1142 gcc-ranlib.cc 55 49196 insn-enums.cc 6 2173 insn-peep.cc 7 2 34 cc1-checksum.cc0 0 3 cc1plus-checksum.cc0 0 3
[Bug target/116278] [15] RISC-V: Miscompile at -O2 -fwrapv -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116278 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org, ||pan2.li at intel dot com --- Comment #2 from Kito Cheng --- Hi Pan, could you take a look to see if it related to SAT_ADD?
[Bug target/116592] illegal operands th.vsetvli zero,0,e32,m8 with -O2 -O3 when compiling for risc-v xtheadvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592 Kito Cheng changed: What|Removed |Added CC||cmuellner at gcc dot gnu.org, ||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- Hi Christoph: Not sure if Vrull is still care theadvector?
[Bug c++/116595] default-initialization of vfloat32m1x4_t (RISCV V) or svfloat32x4_t (Armv9-a SVE) causes ICE
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
[Bug c++/116595] default-initialization of vfloat32m1x4_t (RISCV V) or svfloat32x4_t (Armv9-a SVE) causes ICE
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
[Bug c/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #1 from Kito Cheng --- Thanks for report! we definitely missed that...
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244
--- Comment #4 from Kito Cheng ---
Gonna commit the fix soon, and following code is the reduced case which is
reduced from your attachment.
Reduced case (reduced by creduce)
typedef int a;
using c = float;
template < typename > using e = int;
#pragma riscv intrinsic "vector"
template < typename, int, int f > struct aa {
using g = int;
template < typename > static constexpr int h() { return f; }
template < typename i > using ab = aa< i, 0, h< i >() >;
};
template < int f > struct p { using j = aa< float, 6, f >; };
template < int f > struct k { using j = typename p< f >::j; };
template < typename, int f > using ac = typename k< f >::j;
template < class ad > using l = typename ad::g;
template < class g, class ad > using ab = typename ad::ab< g >;
template < class ad > using ae = ab< e< ad >, ad >;
template < int m > vuint32mf2_t ai(aa< a, m, -1 >, a aj) {
return __riscv_vmv_v_x_u32mf2(aj, 0);
}
template < int m > vfloat32mf2_t ai(aa< c, m, -1 >, c);
template < class ad > using ak = decltype(ai(ad(), l< ad >()));
template < class ad > ak< ad > al(ad d) {
ae< decltype(d) > am;
return an(d, ai(am, 0));
}
template < typename g, int m > vuint8mf2_t ao(aa< g, m, -1 >, vuint32mf2_t n) {
return __riscv_vreinterpret_v_u32mf2_u8mf2(n);
}
template < int m > vuint32mf2_t ap(aa< a, m, -1 >, vuint8mf2_t n) {
return __riscv_vreinterpret_v_u8mf2_u32mf2(n);
}
template < typename g, int m > vuint8mf2_t ao(aa< g, m, -1 >, vfloat32mf2_t n)
{
return __riscv_vreinterpret_v_u32mf2_u8mf2(
__riscv_vreinterpret_v_f32mf2_u32mf2(n));
}
template < int m > vfloat32mf2_t ap(aa< c, m, -1 >, vuint8mf2_t);
template < class ad, class aq > ak< ad > an(ad d, aq n) {
return ap(d, ao(d, n));
}
vbool64_t av(vuint32mf2_t, vuint32mf2_t);
template < class ad > bool ba(ad, vbool64_t);
template < class ad > using bb = decltype(al(ad()));
template < typename g > using be = ac< g, -1 >;
struct bf {
template < class ad > bool bh(ad, bb< ad > bi) {
ae< ad > am;
return ba(am, av(an(am, bi), al(am)));
}
};
int bo;
template < class ad, class bl, typename g > void o(ad d, bl bn, g) {
bb< ad > bq = al(d);
for (; bo;) {
int br = bn.bh(d, bq);
if (__builtin_expect(br, 0))
for (;;)
;
}
}
template < class ad, class bl, typename g > void bs(ad d, bl bn, g) {
g bu;
o(d, bn, bu);
}
template < class ad, class bl, typename g >
void bv(ad d, bl bn, g *, int, g *bt) {
bs(d, bn, bt);
}
float by;
int bz;
float ca;
void b() {
be< float > d;
bf bn;
bv(d, bn, &by, bz, &ca);
}
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Kito Cheng --- Fixed, let us know if you got any issue on compiling or testing highway!
[Bug target/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Kito Cheng --- Fixed!
[Bug target/109312] Missing __riscv_v_intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109312 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Kito Cheng --- Fixed, let me know if you got any issue on RVV intrinsic, thanks :)
[Bug target/109328] [13 Regression] Build fail in RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Kito Cheng --- I can reproduce the problem with crosstool-ng, and it has resolved by Andrew Pinski's fix, I am reviewing the dependency in the file. Plan to drop a complete version of patch later :)
