https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121778
--- Comment #5 from Jeffrey A. Law ---
Yea, I don't see a great target in the rv64 dumps.
As far as the patch itself. I'd bet we want to change all those SIs to X so
that it works on rv64 on a comparable testcase like:
unsigned long test_011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121983
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985
--- Comment #5 from Jeffrey A. Law ---
Somehow ranger is mucking things up.
=== BB 2
Imports: var_8
Exports: var_8
[local count: 153437704]:
var_8 = f;
pretmp_23 = a;
if (var_8 <= 5)
goto ; [85.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121983
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-09-18
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121910
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121982
Jeffrey A. Law changed:
What|Removed |Added
Assignee|law at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121985
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121512
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #31 from Jeffrey A. Law ---
*** Bug 121512 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 121512, which changed state.
Bug 121512 Summary: internal compiler error: in generate_insn, at
config/riscv/riscv-vector-builtins.cc:4470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121512
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58727
--- Comment #7 from Jeffrey A. Law ---
So part of the problem here is the ARM and x86 ports will accept the
"simplified" constant in their AND patterns. The ARM port will eventually
split it into components, but by then it's too late to clean th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121889
--- Comment #4 from Jeffrey A. Law ---
Doesn't really make much sense to me. Your error is way up in the front-end
while the fusion change is deep in the RTL pipeline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108016
--- Comment #15 from Jeffrey A. Law ---
WRT c#14. Yes, if had a stack object and the references to it go away during
the later optimization phases, then the useless stack adjustments will be left
lying around. I don't have the PR for that prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #10 from Jeffrey A. Law ---
Just a quick update. We're seeing really good results with Shreya's in-flight
work. Hoping to test cactusBSSN on design this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121652
--- Comment #16 from Jeffrey A. Law ---
WRT c#13, yes, it's worth it, the performance gains were huge. Of course if we
look out Zfa should become ubiquitious and that other path won't matter. But
we're not at that point yet IMHO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57650
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
|UNCONFIRMED |RESOLVED
CC||law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law ---
Verified Robin's fix for 121523 fixes this one too.
*** This bug has been marked as a duplicate of bug 121523 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 121660, which changed state.
Bug 121660 Summary: [16 Regression] RISC-V: internal compiler error: in
apply_scale, at profile-count.h:1187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121660
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121523
Jeffrey A. Law changed:
What|Removed |Added
CC||skothadiya at whileone dot in
--- Comm
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
unsigned int
test_011 (unsigned int a, unsigned int b)
{
return (a << 1) | ((a >> 31) ^ 1);
}
Seems like that's a rotate left by 1 bit position, then an inversi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65266
--- Comment #1 from Jeffrey A. Law ---
So I took at peek at this as it looked like it might be an interesting missed
optimization case for one my interns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121213
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121548
Jeffrey A. Law changed:
What|Removed |Added
Blocks|120763 |
Status|NEW
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
arc-elf started failing graphite/id-13.c with an ICE in vect_build_slp_tree_2
after this change:
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89828
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99951
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101822
Bug 101822 depends on bug 7, which changed state.
Bug 7 Summary: Missed optimisation with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
--- Comment #8 from Jeffrey A. Law ---
Seems to be fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121548
Jeffrey A. Law changed:
What|Removed |Added
Summary|[15/16 Regression] ICE: |[15 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964
Bug 65964 depends on bug 14617, which changed state.
Bug 14617 Summary: [tree-ssa] suboptimal code ('0' <= c && c <= '9') ? c - '0'
: 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14617
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14617
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117169
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118037
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121213
--- Comment #6 from Jeffrey A. Law ---
And you'll note the bug is still open and that Austin explicitly indicated the
redundant sign extend is still in there. That's a separate issue that needs a
completely different approach to solve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121268
Jeffrey A. Law changed:
What|Removed |Added
Blocks|120763 |
--- Comment #2 from Jeffrey A. Law -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121548
--- Comment #1 from Jeffrey A. Law ---
It looks like we're unconditionally trying to get the merge_op_idx on an insn
that doesn't support that:
(insn 16 15 17 2 (set (subreg:V1DF (reg:RVVM1DF 149 [ _4 ]) 0)
(mem:V1DF (reg/f:DI 151 [ q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121548
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-08-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121656
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #9 from Jeffrey A. Law ---
Costing should prevent mvconst_internal from causing problems in this case.
>From the compiler's current cost model mvconst_internal+add has the same cost
as addi+addi. So there's no reason for combine to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121498
--- Comment #11 from Jeffrey A. Law ---
I still need to throw it under a debugger, but I suspect it's the whole
prologue/epilogue shrink wrapping that's the problem here. The component based
shrink wrapping code excludes RA.
Assuming that's th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120553
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121523
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 120141, which changed state.
Bug 120141 Summary: [RVV] Noop are not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120141
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120141
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118618
Jeffrey A. Law changed:
What|Removed |Added
Blocks|120763 |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121538
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121538
--- Comment #3 from Jeffrey A. Law ---
Fixed by Dimitar's patch on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119275
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121543
--- Comment #2 from Jeffrey A. Law ---
Backported to the gcc-15 branch now :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121531
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120674
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121136
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 121113, which changed state.
Bug 121113 Summary: ICE: in riscv_sched_variable_issue, at
config/riscv/riscv.cc:10243 with -mcpu=xiangshan-kunminghu and _Float16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121113
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121113
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121498
--- Comment #7 from Jeffrey A. Law ---
Note that GCC considers RA a fixed register because of its hidden uses. RA is
not available to the regsiter allocator. There is special code to save/restore
RA if the function is not a leaf function OR if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121334
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #6 from Jeffrey A. Law ---
It does look viable to fix this problem using Shreya's work. But there's one
notable caveat.
So I created an expander "addptr3" which is the magic expander that gets
used by LRA when it needs to reload ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121113
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120603
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121213
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-08-10
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714
Jeffrey A. Law changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121223
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-07-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121160
--- Comment #2 from Jeffrey A. Law ---
So I think we just need to avoid forcing the values into a word_mode register
when they're not an integral mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120920
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Blocks|120763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121160
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121160
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Jeffrey A. Law changed:
What|Removed |Added
Assignee|vineetg at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120553
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120404
Jeffrey A. Law changed:
What|Removed |Added
Assignee|vineetg at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120479
--- Comment #5 from Jeffrey A. Law ---
Deferring indefinitely as I don't see a way to generate a czero right now due
to the multiple use issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120603
Jeffrey A. Law changed:
What|Removed |Added
CC||smunnangi1 at ventanamicro dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
Jeffrey A. Law changed:
What|Removed |Added
CC||smunnangi1 at ventanamicro dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121019
--- Comment #1 from Jeffrey A. Law ---
Per call today, deferring this idefinitely. If someone wants to pick it up,
then by all means, please do. It's just not that high a priority.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120920
--- Comment #2 from Jeffrey A. Law ---
Dusan posted a patch here, but I'm not convinced it's correct. Also note the
patch failed its own test:
https://patchwork.sourceware.org/project/gcc/patch/pr3pr08mb5738ed049e790435a3b5a8aebe...@pr3pr08mb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-07-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118241
--- Comment #17 from Jeffrey A. Law ---
The 4 patches in this space (two from me, two from Vineet) were backported to
the gcc-15 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 120356, which changed state.
Bug 120356 Summary: [15 Regression] RISC-V: Miscompile at -O[23] since
r15-6881-g7b815107f40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 120995, which changed state.
Bug 120995 Summary: [15 regression] [RISC-V] ICE: unrecognizable insn
UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120995
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120995
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This change is causing regressions on the RISC-V port:
commit 4b47acfe2b626d1276e229a0cf165e934813df6c (HEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 119267, which changed state.
Bug 119267 Summary: RISC-V: gcc generates vsetivli with wrong LMUL with
extended assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267
Jeffrey A. Law changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116363
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
rv32 has 32bit GPRs, yet the port defines DI patterns. In the past that was
commonplace to improve performance, but it can sometimes be harmful.
So the goal is to evaluate if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120995
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
Last
|NEW
Assignee|rdapp.gcc at gmail dot com |law at gcc dot gnu.org
CC||majin at gcc dot gnu.org
Last reconfirmed||2025-07-07
--- Comment #1 from Jeffrey A. Law ---
So if I'm reading every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120920
--- Comment #1 from Jeffrey A. Law ---
This looks fairly painful to capture in a backend pattern; I didn't see any
particular attempt by combine that looked like a promising target pattern.
I suspect you'll need to look at a simplify-rtx simpli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Jeffrey A. Law changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #10 from Jeffrey A. Law ---
So I don't mind these changes being tagged to pr119100. My only concern is how
do we know when we're done on this bug?
We don't need to figure it out right now, but we do need to keep that question
in mi
1 - 100 of 1910 matches
Mail list logo