https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95636
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99347
Jeffrey A. Law changed:
What|Removed |Added
CC||qianchao9 at huawei dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
Jeffrey A. Law changed:
What|Removed |Added
Summary|[11 Regression] ICE in |[10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #12 from Jeffrey A. Law ---
IIRC LSM is quite restricted in the types of MEM expressions it will optimize.
In particular I think they have to be SYMBOL_REFs which severely limits LSM's
effectiveness.
I would support removing it give
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #22 from Jeffrey A. Law ---
I have vague memories of it, but it wasn't my code. It was actually Craig
Burley. It's original purpose was merely to allow converting *_DIV_EXPR into
EXACT_DIV_EXPR which presumably was important for so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727
Bug ID: 100727
Summary: [12 Regression] Recent change to WITH_SIZE_EXPR
handling breaks mn10300-elf
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100727
--- Comment #1 from Jeffrey A. Law ---
The v850-elf port is also seeing these failures in some of its multilib
configurations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100730
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100730
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96674, which changed state.
Bug 96674 Summary: Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
--- Comment #7 from Jeffrey A. Law ---
So when we're finding jump threads we know if we thread through the loop latch
and we note when that's going to create an irreducible region. We generally
suppress threading through the latch before the l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2023-01-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108723
Bug ID: 108723
Summary: [13 Regression] Recent changes broke risc-v testsuite
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #5 from Jeffrey A. Law ---
So a datapoint in this effort.
For the Veyron V1, all the bitmanip instructions except clmul and cpop are
single cycle and can be handled by any of the 4 standard ALUs.
clmul, cpop are 4c and use the shar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108764
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092
--- Comment #4 from Jeffrey A. Law ---
Also note there's an unsafe REGNO in peephole.md as well. Slightly different in
form, but still unprotected and thus for well crafted inputs could probably
cause an ICE or incorrect codegen (in a non-checki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
--- Comment #19 from Jeffrey A. Law ---
I stumbled over this as well as some point. One thing I started playing with,
but had to set aside was making vect_get_range_info smarter.
In particular the case I was looking at VAR would have a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895
--- Comment #9 from Jeffrey A. Law ---
Yea, no need to backport this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895
--- Comment #10 from Jeffrey A. Law ---
And just an FYI. As expected this resolves the regression on our internal
target. Thanks Roger!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #12 from Jeffrey A. Law ---
Just to confirm. Yes, that patch fixed the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
Bug ID: 104987
Summary: [12 Regression] Recent change causing vrp13.c
regressions on several targets
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86224
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #2 from Jeffrey A. Law ---
It does trigger execution failures on those targets.
I guess it's possible it's merely exposing existing bugs on those targets. If
we were inlining before, we may have collapsed the test away completely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #6 from Jeffrey A. Law ---
For the v850 at least, I'm starting to think this is a simulator bug. In
particular the simulator code doesn't look safe on a 64bit host for a signed
input to the MUL instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #7 from Jeffrey A. Law ---
Highly confident this is a simulator bug for the v850. I hiaven't looked at
iq2000-elf yet, but I wouldn't be surprised if that turns out to be something
similar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
Jeffrey A. Law changed:
What|Removed |Added
Target|iq2000-elf, v850e-elf |iq2000-elf
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #8 from Jeffrey A. Law ---
First, there's magic bits which turn a standard sqrt call into something like
if (exceptional condition)
call libm's sqrt
else
use hardware sqrt
The primary goal is to get errno set properly for those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107119
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
--- Comment #2 from Jeffrey A. Law ---
Which is just uber-weird. The change in question removes a little subloop
which becomes unreachable. Why that would cause us to be unable to analyze the
remaining key loop for the IV's range is a complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
--- Comment #4 from Jeffrey A. Law ---
I'll double check, but IIRC we throw away the loop structures at the end of DOM
and they're supposed to be rebuilt (which appears to be happening as we
re-construct LCSSA).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
--- Comment #3 from Jeffrey A. Law ---
Testing a trivial patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107229
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
Bug ID: 107275
Summary: [13 Regression] Recent ifcvt changes resulting in
references to SSA_NAME on free list
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
--- Comment #6 from Jeffrey A. Law ---
So this issue has come up again in the context of LRA conversion which happens
to trip over the same bug, but with a different testcase.
At the core of this problem is reload and LRA will both generate inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
Jeffrey A. Law changed:
What|Removed |Added
Summary|[11/12/13 regression] ICE |[11/12 regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103974
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103974
--- Comment #8 from Jeffrey A. Law ---
ACK. I wandered through the tester this morning, the vast majority of the
current failures are the ira_flattening ICE. Though I think there's likely one
other ICE in IRA (frv-elf, ICE in check_allocation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #6 from Jeffrey A. Law ---
And just to follow-up. With the patch that was committed to the trunk, the 30+
targets that were previously failing are now working.
A few are still building, but I expect them to succeed. mips* is faili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #11 from Jeffrey A. Law ---
We can assume that the result of a POINTER_PLUS is non-null if either argument
is non-null. So X + constant is always non-null. X + Y would be non-null if
either X or Y is known to be non-null.
If we kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
--- Comment #5 from Jeffrey A. Law ---
I briefly looked at the other BZ last week, but didn't make much headway. The
first thing that stood out was why are we threading around the loop. I thought
that was disabled. Anyway, Aldy and/or I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
--- Comment #5 from Jeffrey A. Law ---
We thread one edge at a time, so we don't know ahead of time how many copies
there would be.
It could be restructured to go ahead and register these threads, then compute
the copy cost on a more global bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #9 from Jeffrey A. Law ---
I think Andrew has raised a really interesting issue. If the relation code is
designed around seeing things in dominator order, then don't we have to stop
using it once we traverse any edge where the edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Bug ID: 104153
Summary: [12 Regression] ICE due to recent ifcvt changes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
Bug ID: 104154
Summary: [12 Regression] Another ICE due to recent ifcvt
changes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #2 from Jeffrey A. Law ---
I'd bet the or1k expanders are changing the passed-in RTL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #4 from Jeffrey A. Law ---
That seems to get newlib building. But I'm also seeing a ton of testsuite
failures. Not sure what's going on with those yet. I'll have to make some
time tomorrow to look at them a bit deeper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #21 from Jeffrey A. Law ---
Yes, the wording is dreadful. Yes we need a better way to express to the user
the paths followed and how they impacted the analysis.
As for suppressing. There's not a great option here, which isn't a hug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 95424, which changed state.
Bug 95424 Summary: Failure to optimize division with numerator of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
--- Comment #7 from Jeffrey A. Law ---
Sorry, I wasn't able to debug those additional failures until the weekend.
They ultimately turned out to be a bug in some recent newlib refactoring. I
got clean or1k builds once I applied your patch and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #34 from Jeffrey A. Law ---
I've always wanted to see us be able to push something like those matched
conversions down through the PHI.
That would make the code look like:
if (x.1_1 > 255)
goto ; [INV]
else
goto ; [INV]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
Bug ID: 104400
Summary: [12 Regression] v850e lra/reload failure after recent
change
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97040
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #4 from Jeffrey A. Law ---
Given we've run this code on a pretty wide variety of targets, I'm not too
concerned. The arc issue was the last one I'm aware of related to your ifcvt
changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97040
--- Comment #2 from Jeffrey A. Law ---
So a bit more background. I was doing some maintenance work on the v850 a few
years back and noticed an issue with e3v5 testing and FMAs. I poked around a
bit and had largely ruled out the generic bits of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97040
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104153
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #5 from Jeffrey A. Law ---
Created attachment 52432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52432&action=edit
Testcase #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
--- Comment #8 from Jeffrey A. Law ---
So the updated patch fixes the arc build regressions. I haven't looked at the
thread with Segher, but I will as soon as I can. Mostly just wanted to let
you know that the updated patch does indeed get th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Bug ID: 103161
Summary: [12 Regression] Better ranges cause
builtin-sprintf-warn-16.c failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #1 from Jeffrey A. Law ---
I suspect the same underlying issue is affecting the test on line #243 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103182
Bug ID: 103182
Summary: [12 Regression] Recent change causes code correctness
regression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103182
--- Comment #4 from Jeffrey A. Law ---
And just to be clear, Andrew's c#1 is correct. It's 45967-2.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Bug ID: 103226
Summary: [12 Regression] Recent change to copy-headers causes
execution failure for gcc.dg/torture/pr80974
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103235
Bug ID: 103235
Summary: [12 Regression] Recent change to atomics triggers ICE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103235
--- Comment #2 from Jeffrey A. Law ---
Can you please double-check? It just reproduced for me. Perhaps you were
missing -I./ which is sometimes needed for cross toolchains to *-linux.
[jlaw@dl360p gcc]$ ./cc1 -O2 pthread_cancel.i -I./ -quiet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #3 from Jeffrey A. Law ---
Agreed on P1 until we understand. If it's target specific P4 seems
appropriate. I don't see this failure on any other target in the tester.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278
Bug ID: 103278
Summary: [12 Regression] Recent change to cddce inhibits switch
optimization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278
--- Comment #3 from Jeffrey A. Law ---
Note we also see these regressions:
rl78-elf
if-to-switch-5
if-to-switch-9
xstormy16-elf
if-to-switch-9
sh3-linux-gnu
sh3eb-linux-gnu
gcc.target/sh/pr51244-19.c, but I think this is fixable with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #10 from Jeffrey A. Law ---
Aldy, the trick is to not build the C++ runtime ;-)
So instead of "make" use "make all-gcc && make all-target-libgcc" to build the
compiler and libgcc runtime. Then use "make install-gcc install-target-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
--- Comment #4 from Jeffrey A. Law ---
I could also set up a toolchain ready-to-debug in an AWS instance that you
could use if that would be helpful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
--- Comment #5 from Jeffrey A. Law ---
Ignore last comment. Meant for a different BZ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #11 from Jeffrey A. Law ---
Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
instance if that would be helpful.
1 - 100 of 1404 matches
Mail list logo
