https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122042
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121623
--- Comment #25 from Richard Biener ---
(In reply to Frank Scheiner from comment #24)
> @Richard:
> Thought I put you in CC. Do you maybe have an idea what in
> 44e065a52fa6069d6c8cacebc8f876840d278dd0 creates this issue for ia64?
The rev. was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122040
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122039
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122034
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> I was thinking about doing this in DCE rather than a secondary pass. Though
> I have to figure out the best way to mark __builtin_stack_save is alive when
> an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122023
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122024
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122027
Richard Biener changed:
What|Removed |Added
Keywords||build
--- Comment #1 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122028
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-09-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121830
--- Comment #11 from Richard Biener ---
(In reply to Sam James from comment #10)
> Please file it separately.
PR122023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122023
--- Comment #1 from Richard Biener ---
t.c:6:10: note: Analyze phi: gvar2_lsm.10_12 = PHI <_4(7),
gvar2_lsm.10_14(3)>
t.c:6:10: note: reduction path: _4 gvar2_lsm.10_12
t.c:6:10: note: reduction: detected reduction
t.c:6:10: note: Detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122026
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection, wrong-code
Last rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122023
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: ---
unsigned int gvar1;
int gvar2;
void f ()
{
unsigned int temp1;
while (gvar1--)
{
temp1 = gvar2;
gvar2 >>= 1;
gvar2 &=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122021
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Priority|P3 |P2
--- Comment #6 from Richard Biener ---
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122012
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
--- Comment #5 from Richard Biener ---
Also reproduces w/o -flto. I do have .gcda and .ii files but there's virtual
function calls in the code making it difficult to do a GIMPLE testcase
(OBJ_TYPE_REF isn't implemented there). The IL differenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
--- Comment #4 from Richard Biener ---
(In reply to Filip Kastl from comment #3)
> Created attachment 62419 [details]
> spec config file to reproduce the ICE with
>
> Yeah, I meant a full FDO run. -fprofile-generate and -fprofile use. Sorry
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
--- Comment #2 from Richard Biener ---
I can't reproduce. Does that require actual FDO aka a -fprofile-generate run?
Seems I cannot get spec to do that, I have the STAGE1/STAGE2 vars set and I see
feedback=1 in the log but it still doesn't do i
||2025-09-19
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Meh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122000
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121997
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121996
Richard Biener changed:
What|Removed |Added
Component|middle-end |rtl-optimization
--- Comment #2 from R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121991
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121981
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121989
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > Still:
> > tree FRE : 43.43 ( 50%) 3299k ( 1%)
>
[...]
>
> I have a patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
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=87615
--- Comment #16 from Richard Biener ---
(In reply to Andrew Pinski from comment #15)
> Still:
> tree FRE : 43.43 ( 50%) 3299k ( 1%)
It's the usual problematic dominated_by_p_w_unex:
Samples: 121K of event 'cycles:P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121983
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121982
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121971
--- Comment #4 from Richard Biener ---
Guess we want a [[shouldtail]] where not tail-calling is OK semantically but
highly desireable for performance. [[musttail]] is like [[always_inline]],
it's considered wrong-code when not possible.
OTOH t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> (In reply to Richard Biener from comment #6)
> > So the issue is not the rev. in question (well, it triggers it). PRE should
> > still work since there is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> So the issue is not the rev. in question (well, it triggers it). PRE should
> still work since there is the unconditional dereference in the loop. And it
> d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121720
--- Comment #6 from Richard Biener ---
So the issue is not the rev. in question (well, it triggers it). PRE should
still work since there is the unconditional dereference in the loop. And it
does when we allow ANTIC_IN to grow again during ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121962
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #48 from Richard Biener ---
OK, so 'location' is relevant for refs like *q_19, and indicates the value of
'q_19' which would need to be remembered along with the stored value. I had
added gcc.dg/torture/2028-1.c for this which f
||missed-optimization,
||wrong-code
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #47 from Richard Biener ---
__BB(2,guessed_local(114863530)):
_7 = __MEM ((const struct pair * const &)&stack);
goto __BB4(precise(134217728));
__BB(4,loop_header(1),guessed_local(1073741824)):
_6 = __MEM ((const struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121949
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-09-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121937
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121935
--- Comment #5 from Richard Biener ---
*** Bug 121932 has been marked as a duplicate of this bug. ***
||rguenth at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
So the issue with the testcase at hand is that appearantly we fail to visit
record_type 0x769a7888 a during free-lang-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121935
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121936
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #10 from Richard Biener ---
(In reply to Nathaniel Shead from comment #7)
> Sorry for the breakage. Looks like I missed walking DECL_ARGUMENTS of a
> FUNCTION_DECL relies on this; the following patch fixes the minimal
> reproducers
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
,
||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|
1 - 100 of 19101 matches
Mail list logo