https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|1
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Last reconfirmed||2024-08-07
Target Milestone|--- |15.0
--- Comment #1 from Roger Sayle ---
Doh! This is almost certainly caused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116275
--- Comment #4 from Roger Sayle ---
Created attachment 58868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58868&action=edit
proposed patch
Here's my proposed fix (the first of two patches) that resolves the ICE with
the testcase. The p
||roger at nextmovesoftware dot
com
Ever confirmed|0 |1
Last reconfirmed||2024-09-09
--- Comment #2 from Roger Sayle ---
The constant ~0 can be materialized on x86 in only three bytes using either of
the sequences "pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #14 from Roger Sayle ---
My apologies for the delay/issues. My bootstrap and regression testing of this
patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the reported
ICE). My plan was to fix/resolve all these befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #5 from Roger Sayle ---
Created attachment 54905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905&action=edit
proposed patch
This patch should fix this problem, by adding another pattern the machine
description to also rec
|RESOLVED
Resolution|--- |FIXED
CC||roger at nextmovesoftware dot
com
Known to work||13.0
--- Comment #10 from Roger Sayle ---
This is now fixed (at the tree level) on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19986
Bug 19986 depends on bug 25186, which changed state.
Bug 25186 Summary: (short)(((int)short_var) <<1) should be folded so that the
shift is done in the short type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186
What|Removed
|--- |12.0
CC||roger at nextmovesoftware dot
com
Known to work||12.0
Status|NEW |RESOLVED
--- Comment #6 from Roger Sayle ---
This (testcase) has now been fixed on mainline
at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #17 from Roger Sayle ---
I've submitted an improved version of my patch for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616527.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Roger Sayle changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109766
Roger Sayle changed:
What|Removed |Added
Last reconfirmed||2023-05-08
Ever confirmed|0
at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #4 from Roger Sayle ---
Doh! The recent popcount(bswap(x)) optimizations shouldn't be changing the
width of the popcount, i.e. the convert? extension needs to be re-inserted,
it's only the bswap that gets elimina
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
--- Comment #5 from Roger Sayle ---
Another interesting (simpler) case of -ffast-math pessimization is:
void foo(_Complex double *c)
{
for (int i=0; i<16; i++)
c[i] += __builtin_complex(1.0,0.0);
}
Again without -ffast-math we vectori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
Roger Sayle changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14/15 Re
||roger at nextmovesoftware dot
com
Status|NEW |RESOLVED
Target Milestone|--- |14.0
--- Comment #6 from Roger Sayle ---
This is now fixed on mainline (for GCC 14 and GCC 15).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
--- Comment #5 from Roger Sayle ---
I'm trying to confirm that there are actually widening multiplications in
464.h264ref (on aarch64), but if anyone's already done an analysis of what
might be causing these performance swings, please do post (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559
Bug 85559 depends on bug 78947, which changed state.
Bug 78947 Summary: sub-optimal code for (bool)(int ? int : int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78947
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021
--- Comment #2 from Roger Sayle ---
Here's a reduced test case that should be unaffected by the pending changes to
how V8QI shifts are expanded. Note that the final "t -= t4" is required to
convince the register allocator to "spill".
typedef s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Roger Sayle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
Roger Sayle changed:
What|Removed |Added
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot
gnu.org
||2024-06-08
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|UNCONFIRMED |ASSIGNED
--- Comment #4 from Roger Sayle ---
Created attachment 58386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58386&
|
CC||roger at nextmovesoftware dot
com
Build|powerpc64-linux-gnu |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #2 from Roger Sayle ---
Created attachment 56162
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56162&action=edit
proof-of-concept patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #3 from Roger Sayle ---
This patch addresses the regression, but probably isn't the correct fix.
The issue is that the backend now has a way of representing the concatenation
of two registers (for example, TI is constructed for two
|NEW
CC||roger at nextmovesoftware dot
com
Last reconfirmed||2023-10-26
||roger at nextmovesoftware dot
com
Ever confirmed|0 |1
Last reconfirmed||2023-10-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
Roger Sayle changed:
What|Removed |Added
Target Milestone|11.5|14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
--- Comment #12 from Roger Sayle ---
Patch proposed (actually two alternatives proposed) at
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636203.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107812
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=80040
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #5 from Roger Sayle ---
Many thanks to Benji for reporting this issue. I&#x
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at nextmovesoftware dot com
Target Milestone: ---
The fix for PR c++/70167 (in GCC 11.3) inadvertently introduced a code quality
regression for simple range-for using initializer lists. The motivating
example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083
--- Comment #2 from Roger Sayle ---
Created attachment 55241
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55241&action=edit
proposed patch
This patch fixes the problem. Bootstrap and regression tests underway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110104
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30829
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
nextmovesoftware dot com |unassigned at gcc dot
gnu.org
--- Comment #1 from Roger Sayle ---
I proposed a fix at
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620823.html
but this was obsoleted by a much more comprehensive patch (for PR79193)
proposed by Jakub just an hour earlier:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109766
--- Comment #3 from Roger Sayle ---
For the record a solution was proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618197.html
but this approach failed review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618278.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52070
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|NEW
Summary|[13/14 Regression]
|1
CC||roger at nextmovesoftware dot
com
Status|UNCONFIRMED |NEW
--- Comment #3 from Roger Sayle ---
The patch recently proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html would
||roger at nextmovesoftware dot
com
--- Comment #2 from Roger Sayle ---
The good news is that this has been fixed in the RTL optimizers/x86 backend,
and GCC-14 currently produces the optimal "mov rax, rdx". However, I agree
with Richard Biener that could/shou
gcc dot gnu.org |roger at
nextmovesoftware dot com
CC||roger at nextmovesoftware dot
com
--- Comment #4 from Roger Sayle ---
Advance warning, the testcase pr91681-1.c will start FAILing (temporarily) due
to changes/improvements in __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110588
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264
--- Comment #9 from Roger Sayle ---
*** Bug 101090 has been marked as a duplicate of this bug. ***
||roger at nextmovesoftware dot
com
Status|NEW |RESOLVED
--- Comment #4 from Roger Sayle ---
Many thanks to Vincent for spotting/confirming that his bug report is a
duplicate of PR 106264, which was fixed in GCC 13.
*** This bug has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 101090, which changed state.
Bug 101090 Summary: incorrect -Wunused-value warning on remquo with constant
values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at nextmovesoftware dot com
Target Milestone: ---
The following four functions should in theory all produce the same code:
typedef unsigned long long v4di __attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #17 from Roger Sayle ---
I think this patch might resolve the problem (or move it somewhere else):
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 9fef2bf6585..218bca905f5 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6274,10 +6274,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #18 from Roger Sayle ---
Please ignore comment #17, the above patch is completely bogus/broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #19 from Roger Sayle ---
Created attachment 56930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56930&action=edit
proposed patch
And now for a patch that does (or should) work. This even contains an
optimization, we middle-e
at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #4 from Roger Sayle ---
I'm testing a patch, for more accurate conversion gains/costs in the
scalar-to-vector pass. Adding -mno-stv will work around the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at nextmovesoftware dot com
Target Milestone: ---
As suggested by Richard Earnshaw, this opens a bugzilla PR for tracking this
issue. All the tests in libatomic currently fail on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #6 from Roger Sayle ---
Sorry for the delay in replying/answering Jakub's questions/comments. Yes,
using a define_insn_and_split in the backend fixes/works around the issue (and
I agree your implementation/refinement in comment #5 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #7 from Roger Sayle ---
Very many thanks to Jeff Law for pointing me to fwprop. The following simple
patch also fixes this regression.
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0c588f8..cbba44e 100644
--- a/gcc/fwprop.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112992
Roger Sayle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #8 from Roger Sayle ---
Now we're in stage4, I'll take this. I'm bootstrapping and regression testing
a variant of my tweak to try_fwprop_subst_pattern. The change in comment #7
can hang loop inde
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #1 from Roger Sayle ---
As there's a patch for this regression (awaiting review), I should upgrade the
PR stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #10 from Roger Sayle ---
A revised and improved patch has been posted for review at
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643062.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91681
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|UNCONFIRMED |NEW
CC||roger at nextmovesoftware dot
com
Ever confirmed|0 |1
--- Comment #6 from Roger Sayle ---
To help diagnose the problem, I came up with this simple patch:
diff --git a/gcc/fwprop.cc b/gcc
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at nextmovesoftware dot com
Target Milestone: ---
This patch is a placeholder for tracking the reported failures of
FAIL: gcc.target/arm/bics_3.c scan-assembler-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #8 from Roger Sayle ---
Created attachment 57190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57190&action=edit
proposed patch
Proposed patch to provide a sane/saner set of rtx_costs for SH. There's plenty
more that could b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #10 from Roger Sayle ---
Hi Oleg. Great question. The "speed" parameter passed to rtx_costs, and
address_cost indicates whether the middle-end is optimizing for peformance, and
interested in the nummber of cycles taken by each inst
301 - 400 of 429 matches
Mail list logo
