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
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
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
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.
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
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
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=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
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This change:
commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8 (refs/bisect/bad)
Author: Andreas Schwab
Date: Wed Jan 25 12:00:09 2023 +0100
riscv: Enable
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=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=108398
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Created attachment 54167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54167=edit
Testcase
I'm assuming this is a regression a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #4 from Jeffrey A. Law ---
Yea, thinking about our uarch, we're going to need finer control as well.
There's a subset that ought to execute in any ALU, but there's another subset
that are bound to a specific ALU and are potentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
--- Comment #2 from Jeffrey A. Law ---
We shouldn't use Zba just for the sake of using Zba; it needs to be profitable.
The folks doing the analysis behind this BZ are only looking at instruction
counts -- they're not really thinking about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #2 from Jeffrey A. Law ---
It can certainly get "unduly weird". Basically such instructions get put at
the end of the ready queue as soon as its input dependencies are satisfied. If
there's only a few such instructions, then the
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: risc-v
If you review scheduling dumps for risc-v you
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: risc-v
int sub2(int a, long long b) {
b = (b << 32) >> 31;
unsigned int x = a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
--- Comment #10 from Jeffrey A. Law ---
Yes. I should have changed the state on this BZ a few weeks back.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
ivopts seems to make a bit of a mess out of this code resulting in the loop
having an unnecessary
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
Compile the following code for rv64 with -O2:
typedef signed long int int64_t;
void
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
This testcase:
typedef signed long int __int64_t;
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #7 from Jeffrey A. Law ---
Raphael and I are poking at this a bit. I can't convince myself that it's
actually safe to use GPR for the bit manipulation patterns.
For rv64 I'm pretty sure the b* instructions are operating on 64bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #5 from Jeffrey A. Law ---
Right. You also have to know the distance from the last probe (possibly an
implicit one) to the start of the alloca space before you can contemplate
eliding the probes in alloca space. There's a hook we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #11 from Jeffrey A. Law ---
Thanks! So the change in question improves the decisions in the predicate
analysis code, which can be best thought of as a filter for the false positives
that are still in the IL.
As I said in my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #9 from Jeffrey A. Law ---
These warnings are certainly sensitive to all kinds of things, so it's possible
it's just gone latent. The only way to be sure would be to bisect all the work
between gcc-12 and the trunk and pour over the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 101770, which changed state.
Bug 101770 Summary: -Wmaybe-uninitialized false alarm with only locals in GNU
diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
What|Removed
|RESOLVED
CC||law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law ---
Seems to be fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629
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=91470
Jeffrey A. Law changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85301, which changed state.
Bug 85301 Summary: bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 84078, which changed state.
Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
What|Removed |Added
|--- |FIXED
CC||law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law ---
Seems to have been fixed on the trunk. Not sure if it was the Aldy's threader
work or Richi's predicate analysis work. Either is plausible. Just happy it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 84078, which changed state.
Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 80548, which changed state.
Bug 80548 Summary: -Wmaybe-uninitialized false positive when an assignment is
added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 57832, which changed state.
Bug 57832 Summary: compiling sha-256 code (xz 5.0.5) generates false warnings
when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
What
||13.0
Resolution|--- |FIXED
CC||law at gcc dot gnu.org
--- Comment #8 from Jeffrey A. Law ---
Seems to have been fixed on the trunk, most likely Richi's work from earlier
this year.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #25
|--- |FIXED
CC||law at gcc dot gnu.org
--- Comment #5 from Jeffrey A. Law ---
Based on comments in bz98341, Ada is bootstrapping as of gcc-12 on m68k again.
||law at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed on the trunk by making tests require nonpic effective target.
||law at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Jeffrey A. Law ---
Resolved by skipping the test on hppa targets.
|--- |FIXED
CC||law at gcc dot gnu.org
--- Comment #3 from Jeffrey A. Law ---
Fixed by skipping this test on hpux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104044
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
|RESOLVED
CC||law at gcc dot gnu.org
--- Comment #13 from Jeffrey A. Law ---
More importantly, we should _not_ be adding the runtime exception to files in
GCC proper. That exception is for the runtime. The fact that files in libgcc
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
Target Milestone: ---
Target: s390-linux-gnu
This change:
commit
||law at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #9 from Jeffrey A. Law ---
It was fixed on the trunk, in time for gcc-12. I can't see that we're likely
to backport to gcc-11 or earlier. So closing as fixed.
||law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103296
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #2 from Jeffrey A. Law ---
ACK. And as I mentioned, the RTL form looks like it ought to be caught by the
SH specific code to optimize T reg handling. I don't care enough about the SH
to try and debug a missed optimization though.
501 - 600 of 1196 matches
Mail list logo
