[Bug tree-optimization/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #9

[Bug target/116085] RISC-V: Miscompile at -O2 with zbb

|NEW CC||law at gcc dot gnu.org Last reconfirmed||2024-07-25 --- Comment #4 from Jeffrey A. Law --- Not ext-dce as far as I can tell. A nice chance of pace.. Might still be mine. Investigating.

[Bug rtl-optimization/116066] ext-dce + uncommitted LoongArch patch breaks libcpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116066 --- Comment #2 from Jeffrey A. Law --- Xi, can you give the latest trunk a fresh try. There's a nonzero chance the patch I just installed for 116039 fixes your problem.There's not enough RTL shown to be sure though.

[Bug rtl-optimization/116039] [15 Regression] rv64gc miscompile at -O3 with -fno-strict-aliasing since r15-1901-g98914f9eba5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116039 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058 --- Comment #11 from Jeffrey A. Law --- The patch looks to do basically the right thing and given Richard knows his code better than I, let's go with it. I'll respin sh4* once it lands upstream to see if there's any change.

[Bug target/116044] [15 Regression] GCN vs. rtl-ssa: Avoid using a stale splay tree root [PR116009]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116044 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3

[Bug rtl-optimization/116039] [15 Regression] rv64gc miscompile at -O3 with -fno-strict-aliasing since r15-1901-g98914f9eba5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116039 --- Comment #2 from Jeffrey A. Law --- Very interesting little testcase. This may be the loongarch bug that was recently reported. It appears the root cause is this insn (from a hacked up version, so the insn #s may not match up perfectly): (

[Bug rtl-optimization/116067] [15 Regression] wrong code at -O2 related to -fext-dce

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116067 --- Comment #4 from Jeffrey A. Law --- And Sam, yes, absolutely OK to just assign anything that looks ext-dce related to me. Hoping with today's change things should start settling down and I can focus on addressing some longer term maintainabi

[Bug rtl-optimization/116037] [15 Regression] wrong code at -O2 with vector masking and add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116037 --- Comment #6 from Jeffrey A. Law --- *** Bug 116067 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/116067] [15 Regression] wrong code at -O2 related to -fext-dce

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116067 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED

[Bug rtl-optimization/116037] [15 Regression] wrong code at -O2 with vector masking and add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116037 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/116064] [15 Regression] SPEC 2017 523.xalancbmk_r failed to build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058 --- Comment #9 from Jeffrey A. Law --- Can't hurt to give it a whirl, I've kept docker container live so that I can patch and restart. Richard S. knows this code far better than I do, so he should probably be the right person to do the review t

[Bug rtl-optimization/116037] [15 Regression] wrong code at -O2 with vector masking and add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116037 --- Comment #3 from Jeffrey A. Law --- So this is fixed by a patch I'm still working on. Essentially I want to stop relying on an empty LIVE_TMP to denote that we skipped a destination's set. That's not quite ready yet, but I think it's damn c

[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #16 from Jeffrey A. Law --- And WRT SUBREG_PROMOTED_P. We already clear it for any pseudo we optimize. See the call to reset_subreg_promoted_p. In general I suspect we're more likely to be incorrectly computing lifetime information

[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #15 from Jeffrey A. Law --- Xi, please file a distinct bug for the loongarch bootstrap failure. If in the end it turns out to be the same failure as this one, when we'll close it as a dup. Please assign that new bug to me. While I

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058 --- Comment #7 from Jeffrey A. Law --- You might be barking up the wrong tree here. My gut tells me this isn't the core problem and a bootstrap with your patch just failed in the exact same place as before. My suspicion is your patch works aro

[Bug target/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058 --- Comment #4 from Jeffrey A. Law --- Note there isn't anything inherently wrong with having a clobber that references the same hard register as another operand. If the clobber occurs before the inputs are consumed then the clobber need marked

[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #18 from Jeffrey A. Law --- And I'll repeat what I said earlier. Someone is going to have to put this under a debugger and understand what's really going on. As far as I can tell that's never been done and while debugging via "i di

[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #17 from Jeffrey A. Law --- It's actually pretty damn simple. ../../gcc/configure --disable-analyzer --prefix=$PREFIX --enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer m68k-linux-gnu

[Bug rtl-optimization/116058] New: [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- Created attachment 58743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58743&action=edit testcase sh4-li

[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #8 from Jeffrey A. Law --- So testing my fix for this bug has exposed another secondary issue. Assuming there's not something else lurking, then plan is to address that secondary issue, then come back to this one, then dive into the

[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 Jeffrey A. Law changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Com

[Bug rtl-optimization/115927] [15 regression] wrong code at -O{2,3} with "-fno-tree-vrp" on x86_64-linux-gnu (nondeterministic behavior)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug rtl-optimization/115916] [15 Regression] wrong code on highway-1.2.0 since r15-2011-ga6f551d079de1d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug rtl-optimization/115876] [15 regression] ext-dce.cc has ubsan issues; shifting negative values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876 --- Comment #8 from Jeffrey A. Law --- Strange. My m68k bootstrap ran just fine, though I used QEMU rather than Anarym. Andreas, I don't guess you still have enough state lying around to get register info and some surrounding assembly code at

[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 --- Comment #5 from Jeffrey A. Law --- Agreed with Pinski here. Or at least let's re-test after fixing 115916.

[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #2 from Jeffrey A. Law --- Fairly sure the root cause is the TImode assignments. Based on what I'm seeing, we may have a problem with vectors as well -- worth keeping mind if there's additional bug reports against ext-dce.

[Bug target/115849] New: RISC-V should improve handling of -0.0 when -fno-signed-zeros is enabled

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- When -fno-signed-zeros is enabled the RISC-V port should treat -0.0 just like 0.0, roughly mirroring other ports like aarch64. A

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 --- Comment #12 from Jeffrey A. Law --- My suggestion is to wait for the LLVM release, then backport whatever we need to be compatible with LLVM.

[Bug target/115591] internal error on global variable-length array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115591 --- Comment #11 from Jeffrey A. Law --- No objections at all. Go for it whenever it's convenient for you.

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2024-07-04 Status|UNCONFIR

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #1

[Bug target/113913] [14] RISC-V: suboptimal code gen for intrinsic vcreate

|--- |FIXED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- This was fixed on the trunk by the introduction of the late-combine patch.

[Bug target/115591] internal error on global variable-length array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115591 --- Comment #8 from Jeffrey A. Law --- Passed without issue. I'll go ahead and ACK the patch here. It's good to go IMHO.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug target/112537] Is there a way to disable cpymem pass for rvv

|--- |FIXED CC||law at gcc dot gnu.org --- Comment #15 from Jeffrey A. Law --- Fixed on the trunk with an option to adjust the stringop expansion strategy.

[Bug target/113014] RISC-V: Redundant zeroing instructions in reduction due to r14-3998-g6223ea766daf7c

||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.

[Bug target/113404] ICE: in to_constant, at poly-int.h:588 with -march=rv64gcv -mbig-endian --param=riscv-vector-abi

|--- |FIXED CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.

[Bug target/113766] ICE: in generate_insn, at config/riscv/riscv-vector-builtins.cc:4186 with (invalid?) __riscv_vfredosum_tu()

||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

||law at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug target/115068] RISC-V: Illegal instruction of vfwadd

|RESOLVED CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.

[Bug target/115093] RISC-V Vector ICE in extract_insn: unrecognizable insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115093 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug target/115591] internal error on global variable-length array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115591 --- Comment #6 from Jeffrey A. Law --- Eric, Just threw this into my tester. Figure ~90 minutes to get back the cross results. I assume that if we go forward that you'll handle putting together a regression test since it's Ada source?

[Bug tree-optimization/115652] [15 Regression] GCN: FAIL: gcc.dg/vect/pr70138-{1,2}.c (internal compiler error: verify_ssa failed)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115652 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug target/115650] [15 Regression] ARC backend bug exposed by late-combine pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115650 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4

[Bug target/115650] New: [15 Regression] ARC backend bug exposed by late-combine pass

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This code generates code that can't be groked by as/ld with -O2: /* { dg-do run } */ int a, b[2]; int main () { lbl: for (;

[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 #6 from Jeffrey A. Law --- floatsisf is going to be called through the libcall interface which has different paths than normal function calls and I don't think the usual type promotion rules apply to libcalls.The details escape m

[Bug target/114139] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114139 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/114139] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450

||law at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1

[Bug target/115500] RISC-V: Performance regression on 1bit test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #7 from Jeffrey A. Law --- And to be clearer, if you look at the two assembly snippets: The problem is about 0: 814dsrlia0,a0,0x13 2: 8905andia0,a0,1 4: e501

[Bug target/115500] RISC-V: Performance regression on 1bit test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #6 from Jeffrey A. Law --- That's going to be a uarch issue if the slli/bltz is slower.

[Bug target/114442] ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:8421 with -O2 -mtune=xiangshan-nanhu

||2024-06-16 Ever confirmed|0 |1 CC||law at gcc dot gnu.org --- Comment #1 from Jeffrey A. Law --- Yes, the xiangshan-nanhu scheduler model needs some serious work. The generic RISC-V code will trigger an ICE

[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404 Bug 115404 depends on bug 115387, which changed state. Bug 115387 Summary: [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387 What|Removed |Adde

[Bug target/113362] RISCV64 divide and remainder with the same operands generates two divide operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113362 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3

[Bug target/115500] RISC-V: Performance regression on 1bit test

||13.1.1 Status|UNCONFIRMED |WAITING CC||law at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-06-16 --- Comment #4 from Jeffrey A. Law

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 --- Comment #4 from Jeffrey A. Law --- Seger, please give some suggestions. At least for the riscv case, I don't see a path forward.

[Bug rtl-optimization/114515] [15 Regression] Failure to use aarch64 lane forms after PR101523

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 Jeffrey A. Law changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478 --- Comment #4 from Jeffrey A. Law --- Roger, that looks pretty reasonable. I suspect we're going to need to do something similar for the sh port which seems to be affected negatively as well.

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails

gcc dot gnu.org |law at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-13 --- Comment #2 from Jeffrey A. Law --- Those look worse than the original, so I don't think we want to blindly change the expected output

[Bug testsuite/115262] [15 regression] gcc.target/powerpc/pr66144-3.c fails after r15-831-g05daf617ea22e1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115262 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #11 from Jeffrey A. Law --- That's not the way we do things. And my bootstraps on m68k are working fine. Last one was 6 days ago. This needs to be debugged by someone with the time/interest on the m68k.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 Jeffrey A. Law changed: What|Removed |Added Priority|P4 |P3

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 --- Comment #4 from Jeffrey A. Law --- Agh. I was looking in the main config directory, not common/config. So it all makes sense now. So if we go back to your original analysis, I think we can say things are behaving correctly and we just nee

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 --- Comment #2 from Jeffrey A. Law --- What still doesn't make sense is why nds32 would be special here. It doesn't do anything special with flag_delete_null_pointer_checks and I don't think it uses any of the address space hooks. So why does

[Bug tree-optimization/115298] New: [15 Regression] Various targets failing DSE tests after recent changes

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- A few targets (nds32be-elf, nds32le-elf, avr-elf) have started failing a few tests after recent aliasing changes: Tests

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

|NEW CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Last reconfirmed||2024-05-25 Target|riscv |riscv,fr30 --- Comment

[Bug rtl-optimization/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038 --- Comment #8 from Jeffrey A. Law --- Yea, I would think we want to avoid anything marked as frame related. Otherwise we have to go back and fixup the CFI nodes and such. Eric, do you want to handle the final bootstrap+regression test? Or do

[Bug target/115142] [14 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 --- Comment #5 from Jeffrey A. Law --- Yes, sorry. I should have removed the 15 tag.

[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4

[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2024-05-18 Status|UNCONFIR

[Bug target/115142] [14/15 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 --- Comment #2 from Jeffrey A. Law --- So just one high level note. Nobody is ever going to do something like "-ftree-ter" without having one of the optimization levels on. It's an option combination that just doesn't make sense. But we still

[Bug target/115123] [15 Regression] RISCV vector scan-assembler failures

||2024-05-16 CC||law at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- I'm pretty sure it's the change in sink heuristics. I backed that out yesterday as a check

[Bug other/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3

[Bug tree-optimization/92539] [11/12/13/14/15 Regression] -Warray-bounds false positive with -O3 (loop unroll?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #12

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 --- Comment #5 from Jeffrey A. Law --- So this seems to have fixed the RISC-V port. Thanks! I'm still seeing some problems on the PRU port though: Tests that now fail, but worked before (1 tests): pru-sim: gcc: gcc.dg/pr71478.c (test for exc

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug tree-optimization/115026] [15 Regression] msp430-elf fails gcc.dg/pr66444.c with prange enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026 --- Comment #7 from Jeffrey A. Law --- So what's the magic to re-enable prange? I can do that and spin a fresh build.

[Bug tree-optimization/115009] [15 regression] AVR: ICE in alloc, at value-range-storage.cc:598

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009 --- Comment #8 from Jeffrey A. Law --- And on msp430-elf we're getting a codegen correctness issue on msp430-elf. gcc.dg/pr66444.c fails in the simulator. The -O2 code difference looks like: *** good.s Thu May 9 20:41:37 2024 --- bad.s

[Bug tree-optimization/115009] [15 regression] AVR: ICE in alloc, at value-range-storage.cc:598

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009 Jeffrey A. Law changed: What|Removed |Added Target|avr |avr, rl78 --- Comment #5 from Jeffrey

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115013 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug tree-optimization/115017] New: [15 Regression] Ranger ICE

Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- Created attachment 58153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58153&action=edit Testcase, compile with -O2 on avr-elf Recent work in Ranger seems to be causing

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996 --- Comment #2 from Jeffrey A. Law --- I don't care about the terminology. We have 3 insns in play. A, B and C. We try to combine A -> B which succeeded before resulting in A, B' and C and which in turn allowed a subsequent A -> C combination

[Bug rtl-optimization/114996] New: [15 Regression] [RISC-V] 2->2 combination no longer occurring

mal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- So this test has started failing on RISC-V after re-introduction of the change to avoid 2->2 combinations when i2 is unc

[Bug target/114885] RISC-V: ICE of unrecog insn when graphite for both the c/c++ and fortran

|--- |FIXED CC||law at gcc dot gnu.org --- Comment #4 from Jeffrey A. Law --- Should be fixed on gcc-14 branch and on the trunk.

[Bug target/114506] RISC-V: expect M8 but M4 generated with dynamic LMUL

|RESOLVED CC||law at gcc dot gnu.org --- Comment #6 from Jeffrey A. Law --- Fixed on the trunk. I would not suggest backporting to the gcc-14 tree as it does not fix a regression. I do expect we'll have a gcc-14 riscv coordin

[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

||law at gcc dot gnu.org

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729 --- Comment #11 from Jeffrey A. Law --- Yup. -fsched-verbose=99 is *very* verbose. But that's the point, to see all the gory details. It can be dialed down, but I've never done so myself. What stands out to me is this: ;;| Pressure co

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

||law at gcc dot gnu.org

[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug analyzer/114677] [13/14 Regression] -Wanalyzer-fd-leak false positive writing to int * param

||law at gcc dot gnu.org

[Bug c++/114709] [12/13/14 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context

||law at gcc dot gnu.org

[Bug target/114741] [14 regression] aarch64 sve: unnecessary fmov for scalar int bit operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729 --- Comment #8 from Jeffrey A. Law --- I didn't even notice you had that testcase attached! I haven't done a deep dive, but the first thing that jumps out is the number of instructions in the ready queue, most likely because of the addressing o

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729 --- Comment #7 from Jeffrey A. Law --- Yes, there are different algorithms. I looked at them a while back when we first noticed the problems with spilling and x264. There was very little difference for specint when we varied the algorithms. I

[Bug rtl-optimization/114729] RISC-V SPEC2017 507.cactu excessive spillls with -fschedule-insns

|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Right. So what I'm most interested in are the scheduler decisions as most likely IRA/LRA are simply

<    1   2   3   4   5   6   7   8   9   10   >