[Bug target/94136] GCC doc for built-in function __builtin___clear_cache() not 100% correct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94136 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org ---

[Bug target/104338] RISC-V: Subword atomics result in library calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #12 from palmer at gcc dot gnu.org --- I've got a somewhat recently rebased version of Patrick's patch floating around, it passed testing but I got hung up on the futex_time64 thing and forgot about it. Not sure if folks think it's t

[Bug rtl-optimization/108826] Inefficient address generation on POWER and RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826 --- Comment #5 from palmer at gcc dot gnu.org --- We've run into a handful of things that look like this before, I'm not sure if it's a backend issue or something more general. There's two patterns here that are frequently bad on RISC-V: "unsign

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831 --- Comment #1 from palmer at gcc dot gnu.org --- I'm not quite sure what the rules on targeting 12 for this one: it's not technically a regression, as it's always been broken, but it is a bug. I'd err on the side of taking a fix, as we're just

[Bug target/104338] RISC-V: Subword atomics result in library calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #5 from palmer at gcc dot gnu.org --- (In reply to rvalue from comment #4) > In short term, maybe we can change the spec to link against libatomic by > default (implemented in > https://github.com/riscv-collab/riscv-gcc/commit/ > 2c48

[Bug target/104338] RISC-V: Subword atomics result in library calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 palmer at gcc dot gnu.org changed: What|Removed |Added CC||kito.cheng at gmail dot com

[Bug target/106517] New: RISC-V: Inefficient Generated Code for Floating Point to Integer Rounds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106517 Bug ID: 106517 Summary: RISC-V: Inefficient Generated Code for Floating Point to Integer Rounds Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug target/106544] riscv_print_operand does not check to see if the operands are valid to do INTVAL on them

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106544 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/106807] New: RISC-V: libatomic routines are infinate loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807 Bug ID: 106807 Summary: RISC-V: libatomic routines are infinate loops Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ta

[Bug target/106807] RISC-V: libatomic routines are infinate loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807 --- Comment #3 from palmer at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #1) > That happens if you use a modified compiler that automatically adds > -latomic, so that configure in libatomic thinks that the builtins are > availab

[Bug middle-end/106818] code is genereated differently with or without 'extern'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug middle-end/106818] code is genereated differently with or without 'extern'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818 --- Comment #8 from palmer at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) > (In reply to baoshan from comment #6) > > > really of unknown alignment then sharing the lui might not work. > > Can you elaborate why shareing the lu

[Bug target/106815] [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106815 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org

[Bug target/104338] New: RISC-V: Subword atomics result in library calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 Bug ID: 104338 Summary: RISC-V: Subword atomics result in library calls Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org ---

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #10 from palmer at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #6) > > (In reply to Jonathan Wakely from comment #5) > > > (In reply to palmer from comment #3) > > > > I

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 --- Comment #10 from palmer at gcc dot gnu.org --- (In reply to Andrew Waterman from comment #9) > On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs > wrote: > > > > https://gcc.gnu.org/bugzilla/show

[Bug tree-optimization/102892] [12/13 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug tree-optimization/102892] [12/13 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 --- Comment #13 from palmer at gcc dot gnu.org --- I just posted a patch that removes the undefined behavior from this test case, with that it links on RISC-V.

[Bug target/105355] -msmall-data-limit= unexpectedly accepts a separate argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105355 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug other/109668] 'python' vs. 'python3'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-29 Ever confirme

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #15 from palmer at gcc dot gnu.org --- It's a little easier to see from the float version of the code. $ cat gcc/testsuite/gcc.dg/c23-stdarg-6.c /* Test C23 variadic functions with no named parameters, or last named parameter wit

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #17 from palmer at gcc dot gnu.org --- (In reply to Edwin Lu from comment #16) > (In reply to palmer from comment #15) > > It's a little easier to see from the float version of the code. > > > > $ cat gcc/testsuite/gcc.dg/c23-stdarg-

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #18 from palmer at gcc dot gnu.org --- (In reply to palmer from comment #17) > (In reply to Edwin Lu from comment #16) > > So if I understand correctly, there may also be a problem where it's trying > > to create that named first argu

[Bug target/110748] RISC-V: optimize store of DF 0.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/110748] RISC-V: optimize store of DF 0.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748 --- Comment #7 from palmer at gcc dot gnu.org --- (In reply to palmer from comment #6) > (In reply to Jeffrey A. Law from comment #5) > > I'd bet it's const_0_operand not allowing CONST_DOUBLE. > > > > The question is what unintended side effect

[Bug target/111020] RFE: RISC-V: ability to cherry-pick additional instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111020 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/111139] RISC-V: improve scalar constants cost model

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-08-24 Ever confirme

[Bug target/111501] RISC-V: non-optimal casting when shifting

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-09-20 Keyword

[Bug c/111518] relro protection not working in riscv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111518 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/104831] RISCV libatomic LR.aq/SC.rl pair insufficient for SEQ_CST

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831 palmer at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |patrick at rivosinc do

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org,

[Bug target/116615] Investigate LOGICAL_OP_NON_SHORT_CIRCUIT for RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615 Palmer Dabbelt changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment

[Bug target/116615] Investigate LOGICAL_OP_NON_SHORT_CIRCUIT for RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615 --- Comment #8 from Palmer Dabbelt --- (In reply to Andrew Pinski from comment #7) > History on LOGICAL_OP_NON_SHORT_CIRCUIT being able to defined differently > from BRANCH_COST. It was originally added for powerpc (2002/2003ish) which > had exp

[Bug target/116615] Investigate LOGICAL_OP_NON_SHORT_CIRCUIT for RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615 --- Comment #9 from Palmer Dabbelt --- (In reply to Xi Ruoyao from comment #3) > FYI on LoongArch it's claimed LOGICAL_OP_NON_SHORT_CIRCUIT=0 mostly helps FP > benchmarks, something like > > /* { dg-options "-O2 -ffast-math -fdump-tree-gimple"

[Bug target/116693] [RISC-V] @tlsdesc generates duplicate assembler labels

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116693 --- Comment #2 from Palmer Dabbelt --- I think something like this diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md index 9f94b5aa023..c64c881d152 100644 --- a/gcc/config/riscv/riscv.md +++ b/gcc/config/riscv/riscv.md @@ -2334

[Bug target/109547] New: RISC-V: Multiple vsetvli for load/store loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547 Bug ID: 109547 Summary: RISC-V: Multiple vsetvli for load/store loop Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tar

[Bug target/104338] RISC-V: Subword atomics result in library calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #20 from palmer at gcc dot gnu.org --- (In reply to rvalue from comment #19) > (In reply to Aurelien Jarno from comment #18) > > I wonder if the following patch should also be backported, as it > > doesn't make sense to link with -lat

[Bug target/114809] [RISC-V RVV] Counting elements might be simpler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114809 palmer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|

[Bug target/115217] New: Register pairs can't be encoded in RISC-V inline asm blocks

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115217 Bug ID: 115217 Summary: Register pairs can't be encoded in RISC-V inline asm blocks Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal P

[Bug target/112295] RISC-V: Short forward branch pessimisation for ALU operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112295 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-10-30 Ever confirme

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112531 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-11-21 Ever confirme

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/109972] RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for 32-bit division/remainder on RV64 without M extension

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972 palmer at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC|

[Bug target/110146] New: ICE in riscv_vector::function_builder::add_unique_function()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110146 Bug ID: 110146 Summary: ICE in riscv_vector::function_builder::add_unique_function() Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug target/110201] RISC-V: __builtin_riscv_sm4ks and __builtin_riscv_sm4ed produce invalid assembly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201 --- Comment #2 from palmer at gcc dot gnu.org --- Do you guys have a test suite for these, or did you just happen to run into it? The intrinsic testing has been a bit of a blind spot in GCC land.

[Bug target/110201] RISC-V: __builtin_riscv_sm4ks and __builtin_riscv_sm4ed produce invalid assembly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201 --- Comment #5 from palmer at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #4) > Yea, the tests aren't great. They'll be better shortly. They'll test > non-constant arguments and out-of-range constants, expecting a suitable > di

[Bug target/110201] RISC-V: __builtin_riscv_sm4ks and __builtin_riscv_sm4ed produce invalid assembly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201 --- Comment #6 from palmer at gcc dot gnu.org --- (In reply to Craig Topper from comment #3) > I don't have a testsuite. I saw that gcc had crypto builtins and I happened > to noticed the tests in gcc weren't passing constant arguments. > > We a

[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989 palmer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989 --- Comment #4 from palmer at gcc dot gnu.org --- I left some cruft in that reproducer, it should have been volatile float f[2]; int x[2]; void func() { x[0] = -1; x[1] = 2; for (int i = 0; i < 1; ++i) f[i] = x[i]; } Not sure what's

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug target/110722] New: FP is Saved/Restored around inline assembly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110722 Bug ID: 110722 Summary: FP is Saved/Restored around inline assembly Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: targ

[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --

[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 --- Comment #13 from palmer at gcc dot gnu.org --- I just stumbled back into this one. I think it's fixed?

[Bug target/113686] [RISC-V] TLS (Local Exec) relaxation on structures (LE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686 palmer at gcc dot gnu.org changed: What|Removed |Added CC||nelsonc1225 at sourceware dot

[Bug target/115687] RISC-V optimization when "lui" instructions can be merged

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-06-27 Ever confirme

[Bug target/115687] RISC-V optimization when "lui" instructions can be merged

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687 --- Comment #4 from palmer at gcc dot gnu.org --- Just poking around a bit: I think this is coming from CSE, which is replacing (insn 5 2 6 2 (set (reg:DI 135) (const_int 16384 [0x4000])) "pr115687.c":7:12 275 {*movdi_64bit} (nil))

[Bug target/115687] RISC-V optimization when "lui" instructions can be merged

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687 --- Comment #5 from palmer at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) > (In reply to Andrew Pinski from comment #2) > > There is some code in cse.cc which does handle this. > > See > > https://gcc.gnu.org/onlinedocs/gccint

[Bug target/115687] RISC-V optimization when "lui" instructions can be merged

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687 --- Comment #8 from Palmer Dabbelt --- (In reply to Andrew Waterman from comment #6) > I note MIPS sets TARGET_CONST_ANCHOR to 0x8000, and that architecture's > ADDIU instruction has a 16-bit immediate. RISC-V's ADDI instruction has a > 12-bit