[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
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 take the suggestion from Andrew, implement that in ipa_increase_alignment pass, I saw the dump file number is 67, but ompdevlow is 92, I am not sure it's late enough or not, since I failed to reproduce the original issue on x86_64 + nvptx + cuda 10.0, I just get some error message seems like unrelated to this alignment issue even with r272181. as /tmp/ccuQhrDr.s, line 26; error : Arguments mismatch for instruction 'mov' as /tmp/ccuQhrDr.s, line 91; error : Arguments mismatch for instruction 'mov' as /tmp/ccuQhrDr.s, line 98; error : Label expected for argument 0 of instruction 'call' as /tmp/ccuQhrDr.s, line 98; fatal : Call target not recognized * Note, as has replaced to ptxas manually, it was https://github.com/MentorEmbedded/nvptx-tools Did you mind tell me how to build the environment to reproduce? My current configure option and version: GCC version g:6b3302da9ef26aa11940f8c0dc92bec19e15c09b CUDA: 10.0 (8.0 install failed on Ubuntu 18.04) x86_64: --disable-bootstrap --disable-multilib --enable-languages=c,c++,lto,fortran --enable-offload-targets=nvptx-none --enable-multiarch --with-cuda-driver=/usr/local/cuda nvptx-none nvptx: --disable-bootstrap --disable-sjlj-exceptions --enable-newlib-io-long-long --target=nvptx-none --enable-as-accelerator-for=x86_64-linux-gnu --enable-languages=c,c++,fortran,lto --program-prefix=nvptx-none- Thanks
[Bug c++/94044] New: internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044 Bug ID: 94044 Summary: internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi Product: gcc Version: 10.0 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-gcc g++.dg/cpp0x/variadic-sizeof4.C -std=c++11 or $ arm-eabi-g++ g++.dg/cpp0x/variadic-sizeof4.C -std=c++14 variadic-sizeof4.C:28:43: internal compiler error: in comptypes, at cp/typeck.c:1490 28 | using wrapped2 = list>; | ^~ 0x8aa6ba comptypes(tree_node*, tree_node*, int) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1489 0x89be7e cp_tree_equal(tree_node*, tree_node*) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/tree.c:3794 0x7d9e42 template_args_equal(tree_node*, tree_node*, bool) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9043 0x7d9af9 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9072 0x8a9ce9 structural_comptypes ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1343 0x8aa5ec structural_comptypes ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1510 0x8aa5ec comptypes(tree_node*, tree_node*, int) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1512 0x7d9f75 template_args_equal(tree_node*, tree_node*, bool) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9024 0x89b960 cp_tree_equal(tree_node*, tree_node*) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/tree.c:3875 0x7d9e42 template_args_equal(tree_node*, tree_node*, bool) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9043 0x7d9af9 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9072 0x7e56e9 spec_hasher::equal(spec_entry*, spec_entry*) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:1703 0x848651 hash_table::find_with_hash(spec_entry* const&, unsigned int) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/hash-table.h:917 0x828cf7 lookup_template_class_1 ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:9680 0x828cf7 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/pt.c:10020 0x86339d finish_template_type(tree_node*, tree_node*, int) ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/semantics.c:3407 0x7b80b4 cp_parser_template_id ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/parser.c:16689 0x7b85a8 cp_parser_class_name ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/parser.c:23626 0x7b330e cp_parser_qualifying_entity ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/parser.c:6738 0x7b330e cp_parser_nested_name_specifier_opt ../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/parser.c:6410 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. No ICE if compile with -std=c++11 Failed since g:9d2d283367a407c1ba9ecdb8590f9295828e25f8 GCC Configure option: riscv64: --target=riscv64-unknown-elf --with-abi=lp64 --with-arch=rv64gc arm: --target=arm-eabi
[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi
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 when -std=c++14, no ICE with -std=gnu++14 or -std=c++11 or -std=gnu++11. so I decide to open a new one :)
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
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?
[Bug tree-optimization/95370] [11 Regression] ICE in execute, at adjust-alignment.c:74 since r11-508-gdfa4fcdba374ed44
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 from Kito Cheng --- It seems like same as PR95237
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
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.
[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c
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 alignment, and alignment shrinking might made the decision become wrong. So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for x86, so that it will set the alignment properly from the beginning. PoC/untested patch attached.
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Kito Cheng --- Just update the status from my side, I have a workable version for exact list of USEs, and under clean up.
[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95252 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Kito Cheng --- Seems like I forgot mention the PR in the ChangeLog so the bot can't detect that, but the ChangeLog is auto-gen now, so I don't know how to fix that. Anyway it already committed into trunk and plan to back port to gcc-10 branch next week. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0e0c1300f9f08608873df5571e14a61308dd0c0
[Bug target/95683] RISC-V: internal compiler error: in riscv_gpr_save_operation_p, at config/riscv/riscv.c:5219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683 Kito Cheng changed: What|Removed |Added Last reconfirmed||2020-06-15 Status|UNCONFIRMED |ASSIGNED CC||kito at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/95683] RISC-V: internal compiler error: in riscv_gpr_save_operation_p, at config/riscv/riscv.c:5219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95683 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Kito Cheng --- Fixed on trunk.
[Bug target/96260] RISC-V: -fsanitize=kernel-address is not available after gcc10
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 from Kito Cheng --- Yeah, seems like I fix PR91441 in wrong way.
[Bug target/96260] [10/11 Regression] RISC-V: -fsanitize=kernel-address is not available after gcc10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96260 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Kito Cheng --- Fixed on GCC 10 branch and trunk.
[Bug sanitizer/96307] 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 Last reconfirmed||2020-07-24 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Kito Cheng --- Confirmed, thanks for report that :)
[Bug target/96759] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-08-24 --- Comment #1 from Kito Cheng --- Confirmed
[Bug target/96759] ICE in extract_insn, at recog.c:2294
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 (nil)) (insn 24 23 25 (set (reg:DF 84) (reg:DF 42 fa0)) "g++.target/riscv/pr96759.C":8:38 -1 (nil)) But it will ICE after GCC 10, try to bisect to figure out the reason.
[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759 --- Comment #3 from Kito Cheng --- ICE after g:70cdb21e579191fe9f0f1d45e328908e59c0179e
[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 #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.
[Bug target/93304] New: RISC-V: Function with interrupt attribute use register without save/restore at prologue/epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93304
Bug ID: 93304
Summary: RISC-V: Function with interrupt attribute use register
without save/restore at prologue/epilogue
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
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/restore at
prologue/epilogue.
The problem is come from register rename pass, it use register not handled at
prologue/epilogue, but it's because RISC-V didn't implement
HARD_REGNO_RENAME_OK.
Version: GCC 8, 9, trunk
Option: -O -frename-registers -march=rv64i -mabi=lp64
Testcase:
static unsigned _timer_ticks = 0;
void m_timer_interrupt(void) __attribute__((interrupt));
void m_timer_interrupt(void)
{
_timer_ticks ++;
}
Code gen (by e4a5f73449d7352ba8128fecbc9a9570d746abdb):
m_timer_interrupt:
addisp,sp,-16
sw a4,12(sp)
sw a5,8(sp)
lui a4,%hi(_timer_ticks)
lw a5,%lo(_timer_ticks)(a4)
addit0,a5,1 #
sw t0,%lo(_timer_ticks)(a4) # t0 are used but it not save/restore
at prologue/epilogue
lw a4,12(sp)
lw a5,8(sp)
addisp,sp,16
mret
Reported by goxin...@gmail.com at RISC-V SW Dev
list
(https://groups.google.com/a/groups.riscv.org/d/msg/sw-dev/w8CCfQwk5DA/ZC0izJvBCAAJ)
[Bug target/93304] RISC-V: Function with interrupt attribute use register without save/restore at prologue/epilogue
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
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
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 from Kito Cheng --- pr90883.C got fail for following target: | fail reason arm-eabi| "Deleted redundant store:" appear dse2 mips-elf| "Deleted dead store: .a[*] = 0;" appear at dse2 mips64-elf | "Deleted dead store: .a[*] = 0;" appear at dse2 nds32le-elf | "Deleted redundant store:" appear dse2 riscv32-elf | "Deleted redundant store:" appear dse2 And configure options: | configure option arm-eabi| --target=arm-eabi mips-elf| --target=mips-elf mips64-elf | --target=mips64-elf nds32le-elf | --target=nds32le-elf riscv32-elf | --target=riscv32-elf --with-arch=rv32gc --with-abi=ilp32d sha1: g:85232b45840330df0fef81f2d4756d9a25d5ac3b
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org, ||wilson at gcc dot gnu.org --- Comment #15 from Kito Cheng --- RISC-V got fail after g:26d7a5e690169ac04acde90070b0092c41b71c7e for gfortran.dg/pr45636.f90 It seems like because alignment change cause simplify_builtin_call can't simplify memset to load/store. The story for RISC-V here: - simplify_builtin_call call can_store_by_pieces check it's OK to store by pieces? - can_store_by_pieces call targetm.use_by_pieces_infrastructure_p to ask back-end - targetm.use_by_pieces_infrastructure_p call by_pieces_ninsns to calculate how many instruction needed, it was 1 for RV64*, because alignment is changed to 8 bits from 64 bits for char array due to this patch g:26d7a5e690169ac04acde90070b0092c41b71c7e. - by_pieces_ninsns got 4 instead of 1, and large than MOVE_RATIO, failed to simplify memset to load/store. - ARM (aarch32) seems like same story too. * Configure option for RV64: --target=riscv64-unknown-linux-gnu --with-arch=rv64gc --with-abi=lp64 Analysis: - align_local_variable changed policy, only ask alignment info (SET_DECL_ALIGN) from back-end only when expanding (expand pass). - So that's cause cost measurement changed, because some cost measurement are depend on the alignment.
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
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 not the right place to update alignment. I write a patch to add a new pass to update the data alignment, executed at begging of pass_all_early_optimizations, PoC patch attached, it's not fully tested yet, how do you think about this approach? Thanks :)
[Bug target/93995] ICE in patch_jump_insn, at cfgrtl.c:1290 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93995 --- Comment #3 from Kito Cheng --- Ooop, confirmed, I am debugging now, thanks your report.
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
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 those 3
targets are expand " = {}" to loop at earlier passes.
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
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_RATIO too, they
should add into xfail list.
Patch here:
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
b/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
index c5faffa1f32..0e622f263d2 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
@@ -1,4 +1,4 @@
-// { dg-options "-O2 -Os -fdump-tree-dse-details -std=c++11" }
+// { dg-options "-O2 -Os -fdump-tree-dse-details -std=c++11 --param
max-inline-insns-size=1" }
class C
@@ -15,6 +15,6 @@
// We want to match enough here to capture that we deleted an empty
// constructor store
-// { dg-final { scan-tree-dump "Deleted redundant store: .*\.a = {}" "dse1" {
target { ! i?86-*-* } } } }
-// { dg-final { scan-tree-dump "Deleted redundant store: .*\.a = {}" "dse2" {
target i?86-*-* } } }
+// aarch64 and mips will expand into loop to clear because CLEAR_RATIO.
+// { dg-final { scan-tree-dump "Deleted redundant store: .*\.a = {}" "dse1" {
xfail { aarch64-*-* mips*-*-* } } } }
[Bug target/93995] [10 Regression] ICE in patch_jump_insn, at cfgrtl.c:1290 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93995 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Hi Martin: Thanks your report again, fixed on trunk now :)
[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target
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-address if TARGET_ASAN_SHADOW_OFFSET is not implemented. - -fsanitize=kernel-address will call targetm.asan_shadow_offset () at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET is not implemented, that's mean -fsanitize=kernel-address is not supported for target without TARGET_ASAN_SHADOW_OFFSET implementation. gcc/ChangeLog: PR target/91441 * toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is implemented for -fsanitize=kernel-address, and merge check logic with -fsanitize=address. testsuite/ChangeLog: PR target/91441 * gcc.target/riscv/pr91441.c: New. Added: trunk/gcc/testsuite/gcc.target/riscv/pr91441.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441 kito at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kito at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from kito at gcc dot gnu.org --- Fixed
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
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 :)
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
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 split pattern with smaller mode than word_mode we should check it's paradoxical subreg or not? Thanks
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
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!
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
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 first back-end use paradoxical_subreg_p :P Hi Jim: Basically my local patch is almost same as Jakub, so I think you can use Jakub's directly if you think that's OK.
[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts
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 the size of a SUBREG_REG doesn't work, so we either need to disable splits if an input is paradoxical, or else we need to generate a clean temporary for intermediate results. Jakub wrote the first version of this patch, so gets primary credit for it. gcc/ PR target/91635 * config/riscv/riscv.md (zero_extendsidi2, zero_extendhi2, extend2): Don't split if paradoxical_subreg_p (operands[0]). (*lshrsi3_zero_extend_3+1, *lshrsi3_zero_extend_3+2): Add clobber and use as intermediate value. gcc/testsuite/ PR target/91635 * gcc.c-torture/execute/pr91635.c: New test. * gcc.target/riscv/shift-shift-4.c: New test. * gcc.target/riscv/shift-shift-5.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91635.c branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-5.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/riscv/riscv.md branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64
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 target/91683 * config/riscv/riscv-protos.h (riscv_split_symbol): New bool parameter. (riscv_move_integer): Likewise. * config/riscv/riscv.c (riscv_split_integer): Pass FALSE for new riscv_move_integer arg. (riscv_legitimize_move): Likewise. (riscv_force_temporary): New parameter in_splitter. Don't call force_reg if true. (riscv_unspec_offset_high): Pass FALSE for new riscv_force_temporary arg. (riscv_add_offset): Likewise. (riscv_split_symbol): New parameter in_splitter. Pass to riscv_force_temporary. (riscv_legitimize_address): Pass FALSE for new riscv_split_symbol arg. (riscv_move_integer): New parameter in_splitter. New local can_create_psuedo. Don't call riscv_split_integer or force_reg when in_splitter TRUE. (riscv_legitimize_const_move): Pass FALSE for new riscv_move_integer, riscv_split_symbol, and riscv_force_temporary args. * config/riscv/riscv.md (low+1): Pass TRUE for new riscv_move_integer arg. (low+2): Pass TRUE for new riscv_split_symbol arg. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/riscv/riscv-protos.h branches/gcc-9-branch/gcc/config/riscv/riscv.c branches/gcc-9-branch/gcc/config/riscv/riscv.md
[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 <https://gcc.gnu.org/bugs/> for instructions.
ICE version:
Trunk, 11, 10
Note:
Work with GCC 9
[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.
