NCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
The output of -fdump-ipa-clones can contain "(null)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Martin Jambor changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #33 from Martin Jambor ---
The patch from comment #32 passes LTO-bootstrap and profiled-LTO-bootstrap on
x86_64-linux. I have asked Honza to look at it and comment, especially on the
decision to put the return VR into clone_info des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
--- Comment #9 from Martin Jambor ---
I have posted a patch with the change proposed by Jakub to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri67c3lbm7q@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #32 from Martin Jambor ---
Created attachment 61119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61119&action=edit
Fixed WIP patch
Right, I forgot to modify output_cgraph_opt_summary_p as well, which was not
necessary for th
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #5 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #27 from Martin Jambor ---
Created attachment 61116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61116&action=edit
WIP and only mildly tested patch
This is my current WIP patch, so far only mildly tested, but which
fixes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Martin Jambor changed:
What|Removed |Added
Assignee|jakub at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
--- Comment #8 from Martin Jambor ---
(In reply to Sam James from comment #6)
> Maybe add the PR119530 testcase as well? It is structurally similar, but it
> lacks vectors so may be more useful food for the fuzzers.
I have that on my TODO list,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
--- Comment #7 from Martin Jambor ---
...and that one consists of the first and second patch in the series at
https://inbox.sourceware.org/gcc-patches/cover.1743458148.git.jamb...@gcc.gnu.org/T/#t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116572
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119530
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
--- Comment #5 from Martin Jambor ---
Created attachment 60939
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60939&action=edit
Simple fix
This patch is a simple fix. I'll submit one streaming the necessary type to
the mailing list thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
Martin Jambor changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #18 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6ldslmk3y@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119493
--- Comment #15 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #12)
> For musttail, perhaps SRA could avoid changing the path from musttail call
> return to the return stmt.
> I've tried
> --- gcc/tree-sra.cc.jj2025-01-02
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #3 from Martin Jambor ---
Let me have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #3 from Martin Jambor ---
Created attachment 60759
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60759&action=edit
Output of -fopt-info-vec in the slow case
Output of -fopt-info-vec in the slow case
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org
Blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #4 from Martin Jambor ---
Created attachment 60760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60760&action=edit
Output of -fopt-info-vec in the fast case
Output of -fopt-info-vec in the fast case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #1 from Martin Jambor ---
Created attachment 60757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60757&action=edit
Perf annotate of the slow case
Perf annotate of the slow case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #2 from Martin Jambor ---
Created attachment 60758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60758&action=edit
Perf annotate of the fast case
Perf annotate of the fast case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116572
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #17 from Martin Jambor ---
After reading from ao_compare::compare_ao_refs, I tend to think the
correct predicate for "tbaa_hazard" from my comment #14 is
types_equal_for_same_type_for_tbaa_p (with the last argument true in
early SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 118318, which changed state.
Bug 118318 Summary: [15 regression] ICE when building firefox-134.0 with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #14 from Martin Jambor ---
So something like the following - which is completely untested, the
type test may be a wrong one, I'd like to think this through a little
more before actually proposing this, but any comments still welcome:
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #13 from Martin Jambor ---
(In reply to rguent...@suse.de from comment #10)
[...]
>
> And still SRA should not use a random RHS "model" to build a new
> LHS access, most definitely not when the original aggrega
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #18 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6bjui45il@virgil.suse.cz/T/#u
||2025-02-28
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #17 from Martin Jambor ---
I am going to test and on Monday I'll propose the following change
which should addre
: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, rguenth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #16 from Martin Jambor ---
(In reply to Jan Hubicka from comment #13)
>
[...]
>
> Here are two calls to + and it is not clear which one triggers the ICE.
> However sum += e->count.ipa (); quite obviously preserves the fact that sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
--- Comment #12 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6tt8i58kq@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86270
--- Comment #20 from Martin Jambor ---
We no longer track Zen1 performence, but this hasbrought about a dramatic
improvement of 465.tonto on our SomeKindOfLake machine:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=464.230.0
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 118125, which changed state.
Bug 118125 Summary: [15 Regression] 7-16% slowdown of 510.parest_r on
x86-64(-v3) since r15-6110-g92e0e0f8177530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118858
Bug 118858 depends on bug 118125, which changed state.
Bug 118125 Summary: [15 Regression] 7-16% slowdown of 510.parest_r on
x86-64(-v3) since r15-6110-g92e0e0f8177530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: tkoenig at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Host: x86_64-linux
Target: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118858
--- Comment #3 from Martin Jambor ---
The reason why I only added cold was not a question of streaming (I don't think
we avoid any this way) but rather me being lazy, in the sense that I really
wanted the cold attribute to go in reasonably quick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #14 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6a5atcvem@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118243
--- Comment #12 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6cyfpcviz@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118243
--- Comment #11 from Martin Jambor ---
(In reply to Richard Biener from comment #9)
> Indeed we don't seem to split a vector in the same way:
>
We do but the constant IPA-CP is different, is it is the entire vector in one
constant, as opposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
--- Comment #10 from Martin Jambor ---
Could be, I am about to re-test and commit a patch for PR 118097 which was
approved on Friday and which addresses use of wrong types for IPA-CP
calculation (the patch alone does not fix this ICE, though).
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118243
--- Comment #10 from Martin Jambor ---
This is an equivalent testcase without OpenMP and especially without iostream,
making dump reading a bit easier:
using complex_t = double __complex__;
struct A {
complex_t value;
A(double r) : valu
: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
As discovered in PR 118125 (where the issue was with lto "front-end"),
builtins only get their att
sion: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Blocks: 63426
Target
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #12 from Martin Jambor ---
The cold attribute is simply and silently dropped on the floor by
decl_attributes (in attribs.cc) in the process of building decls for
builtins because it cannot look it up in the gnu attribute name space
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #10 from Martin Jambor ---
For some reason, unlikely_executed_stmt_p (and thus
unlikely_executed_bb_p) do not see that __builtin_unreachable is a
cold function:
(gdb) pt decl
>
QI
size
unit-size
al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #11 from Martin Jambor ---
The issue can also be reproduced with applying:
diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
index 33f19365ec3..4c062fe8a0e 100644
--- a/gcc/ipa-fnsummary.cc
+++ b/gcc/ipa-fnsummary.cc
@@ -255,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 118683, which changed state.
Bug 118683 Summary: UBSAN: Invalid value for type ar_type since
r15-7070-g0d1e62b83561ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118683
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #9 from Martin Jambor ---
Passing -fdisable-tree-rebuild_frequencies1 to the LTO linking step
brings back the original performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #8 from Martin Jambor ---
I guess I should have started with looking at annotated assembly. The
hot loop in the hot functions changes from:
53 : ,-> 5534e0: lea(%r11,%rax,1),%rsi
659 : | 5534e4: mov(%rsi),%edi
48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #7 from Martin Jambor ---
(In reply to Martin Jambor from comment #4)
> [...] Unfortunately when I
> then looked at SLP vectorization when all IPA-VR propagations were
> allowed again, this particular case was not there (but there we
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: anlauf at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Host: x86_64-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892
--- Comment #8 from Martin Jambor ---
I have proposed a patch to address this on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6zfjce03l@virgil.suse.cz/T/#u
|hubicka at gcc dot gnu.org |jamborm at gcc dot
gnu.org
CC||jamborm at gcc dot gnu.org
--- Comment #7 from Martin Jambor ---
I'm about to test a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #4 from Martin Jambor ---
Redirecting the call to operator delete[](void*) to
__builtin_unreachable(), which seems the correct thing to do, leads to
one more SLP vectorization in the functin experiencing the slow-down,
comparing -fop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #33 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6frlax0fz@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #3 from Martin Jambor ---
Unfortunately I have lost access to the machine where I was debugging this due
to some networking issue. Just before that I have discovered that an extra SLP
vectorization in the slow version of the hottest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
--- Comment #2 from Martin Jambor ---
On top if r15-7055-g459816efa13d9d I added a patch adding a
dbg_counter to limit the updates.
The slow-down is caused by two updates of value ranges in jump
function, both of which are necessary to get the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118535
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Martin Jambor changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #31 from Martin Jambor ---
(In reply to Sam James from comment #30)
> FWIW, I haven't hit this in the wild at all, so it's not pressing for me at
> least even if ofc it should be fixed before release.
It certainly has to be fixed, I
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #29 from Martin Jambor ---
(In reply to Sam James from comment #28)
> The testcase from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097#c26
> fails on trunk still.
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
--- Comment #7 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y0zq5oni@virgil.suse.cz/T/#u
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #6 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059
--- Comment #5 from Martin Jambor ---
Indeed, our UBSAN testsuite results are green again, thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
--- Comment #3 from Martin Jambor ---
I'll have a look, though I may not be able to do so in December.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #11 from Martin Jambor ---
IIUC only the simplest testcase of the three was fixed. I'll try to re-check
soon-ish.
: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
In r15-6296-g5d740f56a16270 (Martin Jambor: ipa: Improve how we derive
value
|1
Status|UNCONFIRMED |NEW
CC||jamborm at gcc dot gnu.org,
||pault at gcc dot gnu.org
--- Comment #1 from Martin Jambor ---
This has started with revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #8 from Martin Jambor ---
I can confirm that our UBSAN bootstrap+testsuite buildbot run passed all tests
and is nicely green again. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117142
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117442
--- Comment #4 from Martin Jambor ---
(In reply to David Malcolm from comment #3)
> Sorry about the regression. Should be fixed by the above patch.
No worries, thanks for a quick fix!
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Blocks: 86656
Target Milestone: ---
Host: x86_64-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #4 from Martin Jambor ---
(In reply to Jeffrey A. Law from comment #3)
> What's interesting is I did a bootstrap with ubsan a while back to chase
> down this stuff. Could be something recently introduced or a path we didn't
> trigge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117142
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117211
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
--- Comment #9 from Martin Jambor ---
Right, sorry, life intervened. But I am aware of the need to backport.
However, there is a problem with the testcase that should be addressed first:
https://inbox.sourceware.org/gcc-patches/ri6v7xud7pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #35 from Martin Jambor ---
(In reply to Richard Biener from comment #34)
> This is fixed, right?
Well, yes, but as part of this I promised to go over all VR bits in ipa-cp.*
and ipa-prop.* which is still only half done. But I do ha
1 - 100 of 1359 matches
Mail list logo
