https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121225
--- Comment #3 from Richard Biener ---
I think the bswap pass should instead re-use the original load and truncate it
instead of emitting another one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121925
--- Comment #3 from Richard Biener ---
(In reply to Tamar Christina from comment #0)
> Given the following vectors
>
> a = [A1 A0]
> b = [C D ]
b = [C B] I suppose?
> c = [E D ]
[..]
> rot0 = [E + A0 * C, D + A0 * B]
> rot90 = [E + A1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121925
--- Comment #1 from Richard Biener ---
The other lane appears after lowering load permutations, but I did not want to
mess with SLP pattern recog, so did not place it before. Possibly load permute
lowering will also break some cases.
This is u
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121870
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121844
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
B
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121814
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121831
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121829
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121802
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-09-05
Status|UNCONFIR
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".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121792
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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 d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121740
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121768
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-09-03
Ever confirmed|0
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121767
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121758
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121757
Bug ID: 121757
Summary: [15/16 Regression] ICE in
rtl_ssa::clobber_info::recompute_group
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121753
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121740
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-09-02
Status|UNCONFIR
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121746
Bug ID: 121746
Summary: ICE in fold_nonarray_ctor_reference
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121744
Bug ID: 121744
Summary: Testing std::bitset isn't vectorized
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121737
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121740
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121737
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121712
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-08-29
Ever confirmed|0
1 - 100 of 8304 matches
Mail list logo