https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121920
--- Comment #6 from Richard Biener ---
So - can you confirm this is now fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121921
--- Comment #3 from Richard Biener ---
We only have e + (b - e):
/* Pattern match
tem1 = (long) ptr1;
tem2 = (long) ptr2;
tem3 = tem2 - tem1;
tem4 = (unsigned long) tem3;
tem5 = ptr1 + tem4;
and produce
tem5 = p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121917
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
,
||rguenth at gcc dot gnu.org
--- Comment #8 from Richard Biener ---
This came up in some x264 discussion again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121909
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121908
Richard Biener changed:
What|Removed |Added
Blocks||53947
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121595
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121829
Richard Biener changed:
What|Removed |Added
Summary|[13/14/15/16 Regression]|[13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121703
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121904
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121870
Richard Biener changed:
What|Removed |Added
Known to work||16.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121893
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121891
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121881
--- Comment #3 from Richard Biener ---
You can't generally do this when alias-sets differ (unless one is zero, which
you can then pick). See the various redundant store issues - you need to
second guess all following reads valid with either ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121876
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121889
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
So we're manually deleting dead EH and abnormal edges which can leave stmts to
fixup unreachable. We can deal with this here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121868
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121863
--- Comment #3 from Richard Biener ---
I do still see any submit turned useless when anubis happens to run on it (but
usually and re-submit fixes that then).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121862
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121861
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121844
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121844
Richard Biener changed:
What|Removed |Added
Known to work||16.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121844
--- Comment #3 from Richard Biener ---
Hmm, it isn't enough to re-order IV creation - we are refering to IP_NORMAL pos
during use rewriting as well:
#1 0x02013101 in stmt_after_ip_normal_pos (loop=0x76e4a200,
stmt=)
at /space/r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121830
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Blocks||107997
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Richard Biener ---
ip_normal_pos doesn't handle loops where the exit block isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121830
--- Comment #5 from Richard Biener ---
Thanks for the interesting testcases. Here we have a double AND reduction
which involves another nested cycle operand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121852
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121853
Richard Biener changed:
What|Removed |Added
Component|c++ |target
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121829
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> I belive it's redirect_edge_and_branch called from split_edge done during
> vectorizer peeling. We are splitting the loop entry edge which produces
> the lab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121829
--- Comment #3 from Richard Biener ---
I belive it's redirect_edge_and_branch called from split_edge done during
vectorizer peeling. We are splitting the loop entry edge which produces
the label copy and then we remove the (temporary) forwarde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121830
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
|NEW
CC||hubicka at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Keywords||wrong-code
Last reconfirmed||2025-09-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121831
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
Let me have a look.
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121806
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121802
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
--- Comment #15 from Richard Biener ---
(In reply to Andrew Pinski from comment #14)
> Seems like if we have:
> ((code_9(D) == 2))
> OR ((code_9(D) >= 3))
>
> this could be simplified down to ((code_9(D) >= 2))
>
> But I don't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
--- Comment #16 from Richard Biener ---
Re-working the predicates to include a new meta-operation IN_RANGE might
help overall efficiency and recovery (IN_RANGE having an irange operand)
and might allow to leverage ranger for the "un-obfuscation".
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
Well, it's not a missing PRE - it's how PRE works. The load from pid.t is only
a partial redundancy on the path from get_pid () if it is actually loaded, but
it isn't on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121757
--- Comment #11 from Richard Biener ---
Created attachment 62315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62315&action=edit
testcase
This is the a.ltrans0.o object. Reproduce with
~/obj-arm-g/gcc> ./lto1 -quiet -dumpbase ./a.ltran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121757
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> Created attachment 62315 [details]
> testcase
>
> This is the a.ltrans0.o object. Reproduce with
>
> ~/obj-arm-g/gcc> ./lto1 -quiet -dumpbase ./a.ltrans0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121757
--- Comment #10 from Richard Biener ---
Backtrace from a cross:
#0 fancy_abort (file=0x34e19d0
"/home/rguenther/src/gcc/gcc/rtl-ssa/accesses.cc", line=53,
function=0x34e1c40
"recompute_group")
at /home/rguenther/src/gcc/gcc/diagnosti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121802
--- Comment #1 from Richard Biener ---
Likely the PPC cost models fault. I'll have a quick look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121768
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121788
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121787
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121737
--- Comment #5 from Richard Biener ---
A related but quite similar issue is that pattern recognition can break the
ability to detect the reduction operation when it's split across multiple
stmts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121685
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121740
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|1
Status|UNCONFIRMED |ASSIGNED
Version|unknown |16.0
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
t.c:4:10: note: Analyze phi: a_lsm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121770
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121756
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121758
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121767
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2025-09-03
Target Milestone|--- |16.0
--- Comment #1 from Richard Biener ---
t.ii:257:34: note: Analyze phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121766
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121756
--- Comment #3 from Richard Biener ---
So we chose to sink the store to after an exit of an irreducible region (which
does not contain a VDEF), but then select_best_block moves the location up
_into_ the irreducible region. A situation
/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121758
--- Comment #6 from Richard Biener ---
So the issue is that in pattern detection we have
t.c:4:10: note: over_widening pattern recognized: patt_27 = (int) patt_17;
t.c:4:10: note: extra pattern stmt: patt_17 = patt_19 & 99;
t.c:4:10: note:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121756
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
||2025-09-02
Priority|P3 |P1
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
Confirmed and mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121753
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121757
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code,
|
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Building qt6-declarative 6.9.2 on armv7 with LTO shows the following:
[ 5414s] FAILED: [code=1] lib/qt6/plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121753
--- Comment #3 from Richard Biener ---
So this is another pattern case breaking reductions, we turn c * 4 into
patt_22 = c.0_1 + c.0_1;
patt_7 = patt_22 + patt_22;
which we cannot handle as reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121754
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2025-09-02
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121754
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #11 from Richard Biener ---
(In reply to Segher Boessenkool from comment #10)
[...]
> > > > where set_noop_p for two MEMs simply dispatches to
> > > > rtx_equal_p && !side_effects_p.
> > >
> > > Yes. Which is completely correct,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121744
Richard Biener changed:
What|Removed |Added
Summary|Testing std::bitset isn't |Testing std::bitset isn't
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The testcase ICEs as follows:
g++ -S ccUHHH1f.C -std=c++23
[...]
../src/ibkr/client/EClient.h:137:37: internal compiler error: Segmentation
fault
0x22f8cff internal_error(char const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121747
--- Comment #2 from Richard Biener ---
Possibly some libiberty/simple-object-* issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121746
--- Comment #1 from Richard Biener ---
Created attachment 62258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62258&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121744
--- Comment #1 from Richard Biener ---
Another inefficency in this testcase is that, of course, DR analysis of the
std::bitset load fails, as { 0, +, 1 } >> 6 isn't affine. So we get an
(eumlated) gather that we fail to fully untangle into sens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121744
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
541.leela_r contains sth along the following:
#include
#include
class Foo
{
public:
void fun (std::bitset<21*21>& blacksq);
std::vector m_mc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121737
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Biener from comment #1)
> >
> > What taget were you testing?
>
> Just aarch64 without SVE enabled. Your dump seems to be without the if p
||aarch64, x86-64-*-*
Last reconfirmed||2025-09-01
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
Note this might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121740
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121737
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121730
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121729
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121726
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Priority|P3
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Priority|P3 |P2
--- Comment #4 from Richard Biener ---
C testcase appreciated. I won't promise anything but to have a closer look
(somewhen later).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130
Bug 115130 depends on bug 88398, which changed state.
Bug 88398 Summary: vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 88398, which changed state.
Bug 88398 Summary: vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 88398, which changed state.
Bug 88398 Summary: vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #9 from Richard Biener ---
(In reply to Segher Boessenkool from comment #8)
> Hi!
>
> (In reply to Richard Biener from comment #7)
> > Wow, and this time it's even combine coming into play!
>
> But it is just something that happens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247
--- Comment #7 from Richard Biener ---
The earlier variants have the known issue that SCEV itself cannot register
additional 'assumptions', niter analysis does not need any there, but the
fact that 'i' and 'j' don't wrap in the comment#4 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61247
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> int foo (int *p, unsigned long sz)
> {
> int sum = 0;
> for (unsigned i = 0; i < sz; ++i)
> sum += p[i];
> return sum;
> }
>
> is a simpler variant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121714
--- Comment #3 from Richard Biener ---
I wonder whether the by-pieces infrastructure can be used to query both target
limits and mode to use? If not, I wonder how difficult it would be to make it
so. Note any > 1 gimple stmt replacement would
|1
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
Estimating # of iterations of loop 1
Analyzing # of iterations of loop 1
exit condition [a_9(D) + 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121704
Richard Biener changed:
What|Removed |Added
Version|unknown |16.0
Last reconfirmed|
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Hmm, yeah ... it's copying uninitialized data to another object where it's
supp
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
int foo (int *p, unsigned long sz)
{
int sum = 0;
for (unsigned i = 0; i < sz; ++i)
sum += p[i];
return sum;
}
is a simpler variant. What works is that we set up to version the loop
with sz_
1 - 100 of 19103 matches
Mail list logo
