https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 94375, which changed state.
Bug 94375 Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast
-march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94400, which changed state.
Bug 94400 Summary: 531.deepsjeng_r is 7% slower at -O2 -march=znver2 than GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94400
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97588
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #10 from Martin Jambor ---
OK, adding an additional check whether tree_could_trap_p is of course easy.
I'll wait a little while if the discussion about get_ref_base_and_extent
perhaps leads to a different solution but if not, I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #7 from Martin Jambor ---
Even our constant folding thinks the unsigned expression wraps around. If I
tell SRA to fold the expression if the base is a string_cst, the invalid
dereference is avoided. My experiment was (I am not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #5 from Martin Jambor ---
Right, the issue is that SRA depends on get_ref_base_and_extent to figure out
what is being accessed (and so whether it is safe) and that function believes
the load is safely from within the array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255
--- Comment #3 from Martin Jambor ---
So SRA sees statements:
n[0][2] = "\t\x02\b";
and later
_11 = n[0][3][4294967294];
The latter loads a scalar sitting inside what the store above
initialized (according to get_ref_base_and_extent) and so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #4 from Martin Jambor ---
Actually no, that would be papering over a bigger problem. After looking at
the issue a bit more, I proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563962.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
Martin Jambor changed:
What|Removed |Added
Component|ipa |c++
--- Comment #3 from Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744
--- Comment #2 from Martin Jambor ---
That cannot be the problem. IPA-SRA re-creates the call statements
and builds them with gimple_build_call_vec (callee_decl, vargs); where
calle_decl is the new function which has had its type adjusted and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98690
--- Comment #3 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563790.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #3 from Martin Jambor ---
Here is what happens. An IPA-CP clone for a particular
devirtualziation context is created but all devirtualziations based on
it are speculative. Then the clone is inlined at one of its call
sites and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jamborm at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 45791, which changed state.
Bug 45791 Summary: Missed devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45791
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50430
--- Comment #5 from Martin Jambor ---
Am I correct thinking that this has been addressed (long time ago)?
The entire optimized dump of the testcase from comment #3 is now the
following, so no missed devirtualization there:
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966
Martin Jambor changed:
What|Removed |Added
Summary|[9/10/11 Regression] run|[9/10/11 Regression] Test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966
--- Comment #13 from Martin Jambor ---
I can confirm this, even on current trunk.
The reason is that runtptests/3 -> tp_sum/5 is not inlined because it
exceeds max-inline-insns-auto. I have to set the param to 43 - the
default is 15 - for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 97816, which changed state.
Bug 97816 Summary: [11 Regression] ICE in good_cloning_opportunity_p, at
ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94406, which changed state.
Bug 94406 Summary: 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with
-Ofast -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94406
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #38 from Martin Jambor ---
*** Bug 97980 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97980
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
--- Comment #5 from Martin Jambor ---
As noted in the commit message above, the ICE will go away but the underlying
issue stays so please keep this opened until I fix it, hopefully no later than
next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97816
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=97695
--- Comment #7 from Martin Jambor ---
(In reply to Jan Hubicka from comment #5)
> I see you have patch, too :)
> However we do not want to copy clone info to every inline clone (since
> the body is materialized just once). The problem is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97695
--- Comment #4 from Martin Jambor ---
And the reason is not copying tree_map in cgraph_node::create_clone
(when called from clone_inlined_nodes). The following should fix it.
In theory we need a mechanism for create_virtual_clone to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97695
--- Comment #3 from Martin Jambor ---
It is a clone materialization problem. IPA-CP clones f.part.0 twice and the
second time tree_function_versioning receives NULL tree_map.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
Martin Jambor changed:
What|Removed |Added
Component|ipa |tree-optimization
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #6 from Martin Jambor ---
I have posted the patch to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556399.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #5 from Martin Jambor ---
And indeed the following avoids the issue:
diff --git a/gcc/tree-complex.c b/gcc/tree-complex.c
index 2e54bbb917c..71ad7c18523 100644
--- a/gcc/tree-complex.c
+++ b/gcc/tree-complex.c
@@ -570,8 +570,10 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97456
--- Comment #4 from Martin Jambor ---
Looking at Martin's reduced testcase
(In reply to Richard Biener from comment #2)
> Confirmed with -fwhole-program -O3 IPA SRA messes things up here cloning
> wrong
> and producing the strange
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96818
--- Comment #10 from Martin Jambor ---
Is this bug still "WAITING" for something?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97319
Bug ID: 97319
Summary: LTO profiledbootstrap (C/C++/Fotran only) fails with a
segfault in selftest
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #18 from Martin Jambor ---
I proposed the patch on the mailing list (I guess I should put Martin's name at
least to the testsuite ChangeLog and probably to both):
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555284.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #15 from Martin Jambor ---
so after Martin asked some good questions, it turns out this should probably be
avoided in ipa-prop, after all, as with, for example (untested):
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #14 from Martin Jambor ---
I can confirm the analysis, except that I see the edge we're trying to
add to the heap as already inlined (as a speculative edge it got
inlined even its caller was). Also just not adding an edge with
501 - 550 of 550 matches
Mail list logo
