https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #19 from Jeffrey A. Law ---
f-m-o runs post-allocation, so the scope of where it's behavior can change
things is narrower. So testing with -fno-schedule-insns isn't going to be
useful, but -fno-schedule-insns2 might.
I'm a bit conc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #6 from Jeffrey A. Law ---
Do we have assembly code around the faulting point (x/20i $pc) and a register
dump (i r)? The biggest concern I'd have with f-m-o on the PA would be the
implicit segment selection that happens on the base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #14 from Jeffrey A. Law ---
As Andrew said, if there's a test that depends on behavior of -INT_MIN, then
the test needs to be fixed. That's undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
--- Comment #8 from Jeffrey A. Law ---
No spills on rv64 either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104387
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
--- Comment #6 from Jeffrey A. Law ---
Created attachment 56480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56480&action=edit
Testcase for fr30-elf -Os -g
||law at gcc dot gnu.org
Last reconfirmed||2023-11-01
Ever confirmed|0 |1
--- Comment #5 from Jeffrey A. Law ---
I've bisected a failure on fr30-elf to the same commit. The failure mode is
different, but given it&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112298
Jeffrey A. Law changed:
What|Removed |Added
Target||h8300
Priority|P3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
long long foo(long long x) { return x << 1; }
Highlights several code inefficiencies WRT DImode values on the H8.
I would expect that defining a reasonable adddi3 an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107885
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
Fixed on the trunk now.
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:
commit 6decda1a35be5764101987c210b5693a0d914e58
Author: Richard Biener
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|RESOLVED
CC||law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law ---
This should be fixed on the trunk now. No plans to backport to the release
branches.
||law at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Jeffrey A. Law ---
Fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111384
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2023-10-07
Ever confirmed|0
|RESOLVED
CC||law at gcc dot gnu.org
--- Comment #5 from Jeffrey A. Law ---
These code generation inefficiences have been fixed. I didn't bisect, but I
would hazard a guess it was Jivan's work on exposing the widening nature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64215
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111670
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Target|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
The H8/SX port can create sequences like
(set (mem (autoinc (reg sp)) (reg_sp))
Here autoinc is PRE_DECEMENT or PRE_INCREMENT addressing modes.
Which is invalid RTL.
I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111467
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=82666
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=77576
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
--- Comment #11 from Jeffrey A. Law ---
Looks viable to me. Are you thinking match.pd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
commit fe48f2651334bc4d96b6df6b2bb6b29fcb732a83
Author: Richard Biener
Date: Fri Jun 9 09:31:14 2023 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110423
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=110308
--- Comment #9 from Jeffrey A. Law ---
Right. It's fairly common with fold-mem-offsets to end up rewriting the
address arithmetic such that we'll have an sp->gpr copy of some sort in the IL.
We'd really like to be able to cprop that copy away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201
--- Comment #4 from Jeffrey A. Law ---
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
diagnostic. They'll also test the extrema of valid constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
||2023-06-17
Ever confirmed|0 |1
CC||law at gcc dot gnu.org
--- Comment #5 from Jeffrey A. Law ---
Note that Pan can cherry pick it into gcc-13. Typically folks wait a week or
so after the patch is on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #23 from Jeffrey A. Law ---
risc-v doesn't have any special instructions to implement add-with-carry or
subtract-with-borrow. Depending on who you talk do, it's either a feature or a
mis-design.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110218
--- Comment #2 from Jeffrey A. Law ---
So what I think was happening was that we would sink past a bunch of
conditionals that were never going to be true thinking that we were moving to a
deeper control nest. So the idea was to use the frequenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110163
--- Comment #2 from Jeffrey A. Law ---
It is a regression for rv64. So probably P4 would be most appropriate.
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Comparing against a constant string is expanded by inline_string_cmp and on
some targets the generated code
||law at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Should be fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #10 from Jeffrey A. Law ---
Created attachment 55218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55218&action=edit
(Incomplete) Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
--- Comment #4 from Jeffrey A. Law ---
Patch was for a different problem. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #9 from Jeffrey A. Law ---
Weird, I don't see the attachment either. I'll extract & upload it again.
WRT costing. fwprop and combine will both query the target rtx costs and will
reject when the target costing model indicates the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
--- Comment #3 from Jeffrey A. Law ---
Created attachment 55185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55185&action=edit
(Incomplete) Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #7 from Jeffrey A. Law ---
Attached is what I cobbled together. It doesn't use magic numbers. But it
doesn't yet handle zero extensions in the simplify-rtx code. But I think it
shows the overall direction fairly well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This patch:
commit cc0e22b3f25d4b2a326322bce711179c02377e6c
Author: Richard Biener
Date: Fri May 12 13:43:27 2023 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #6 from Jeffrey A. Law ---
I would still rather not introduce special cases for SUBREGs if we can avoid
it. I think the question remains whether or not patching simplify-rtx's
canonicalize_shift is sufficient to fix this problem (pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109777
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109776
--- Comment #7 from Jeffrey A. Law ---
Thanks. That took care of the xstormy16 issues.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This change:
commit 21e2ef2dc25de318de29ec32d5390350c6717c6a (refs/bisect/bad)
Author: Andrew Pinski
Date: Tue May 2 00:10:46
: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
pr81192 is failing on some targets (xstormy16-elf for example) after this
change:
commit
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
arc-elf target.
FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2
times." 2
Bisection
||2023-04-29
CC||law at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law ---
Similar failures on arc-elf:
arc-sim: gcc.c-torture/execute/pr36691.c -O3 -fomit-frame-pointer
-funroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Target|x86_64-*-* |s390
Summary|[14 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #11 from Jeffrey A. Law ---
Coming back to this.
WRT extension elimination. I've been pondering if we want a late pass to do a
bit of this that can't be handled by REE.
So let's take the case of a Zbs instruction operating on a va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #4 from Jeffrey A. Law ---
If we need to handle subregs here, I would suggest something like this
if (SUBREG_P (XEXP (op0, 0))
&& subreg_lowpart_p (op0)
... other tests ...
That way we know we're extracting the low word of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #10 from Jeffrey A. Law ---
The sign_extend later gets turned into zero_extend. Presumably because we know
the value is never negative. That in and of itself wouldn't be a big deal as
it should be easily recognizable using any_exte
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This is a trivial sign extension:
int sextb32(int x)
{ return (x << 24) >> 24; }
Yet on RV64 with ZBB enabled we get:
sextb32:
slli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #8 from Jeffrey A. Law ---
So coming back to this after a couple months, I'm confident the match.pd change
is unnecessary and in fact wrong. So we definitely want to set that aside.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #6 from Jeffrey A. Law ---
Comment on attachment 54905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905
proposed patch
So that's a subset of what we've done. We initially thought that was going to
be enough to solve this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #4 from Jeffrey A. Law ---
Vineet, we've got some bits here you might want to play with. I'm about to
leave for the evening, but I'll put you in touch with Raphael tomorrow
afternoon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #6 from Jeffrey A. Law ---
And just an FYI, the tester is flagging conditional move failures for mips64-*
rx-elf and s390-linux-gnu. Most likely these are additional cases where the
hook is indicating the transformation isn't profit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #4 from Jeffrey A. Law ---
x86's tuning does have some support for avoiding multiple cmovs in a single
if-converted sequence. I'll double check if that's kicking in here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
--- Comment #7 from Jeffrey A. Law ---
Once you've committed to the active release branches where this bug is active
(11/12 in this case), you can just close the bug as resolved/fixed. No need to
update the summary/title in that case.
Thanks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
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=109508
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103602
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103829
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478
--- Comment #2 from Jeffrey A. Law ---
The pa.cc bits look reasonable. It's been forever since I looked at this code,
but clearly using a HOST_WIDE_INT is the right thing to be doing. While it may
not fix this bug completely, consider it pre-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105628
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108358
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947
--- Comment #2 from Jeffrey A. Law ---
*** Bug 109040 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
--- Comment #5 from Jeffrey A. Law ---
Right. The fix is a 1-liner. I had it going through a test on x86 and riscv
and lost power. Finally got it re-spun and just need to look at the results.
601 - 700 of 1352 matches
Mail list logo
