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
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
Martin Jambor changed:
What|Removed |Added
Component|ipa |tree-optimization
--- Comment #7 from
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=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
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 #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=97456
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=97980
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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 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=94406
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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=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=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 #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=97578
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=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=58243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=98744
Martin Jambor changed:
What|Removed |Added
Component|ipa |c++
--- Comment #3 from Martin Jambor
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=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 #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 #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 #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=98222
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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=98222
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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=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=100453
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90404
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573338.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
--- Comment #13 from Martin Jambor ---
Another attempt to fix this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572814.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
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=100453
--- Comment #4 from Martin Jambor ---
I proposed a patch to address this on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570267.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100491
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100597
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100539
Martin Jambor changed:
What|Removed |Added
Component|rtl-optimization|ipa
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Martin Jambor changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
Bug ID: 101296
Summary: Addition of x86 addsub SLP patterned slowed down
433.milc by 12% on znver2 with -Ofast -flto
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
--- Comment #1 from Martin Jambor ---
For the reference, this is the backtrace:
mjambor@virgil:/tmp/bbb$ ~/gcc/trunk/inst/bin/gcc -S -Ofast test.i
during GIMPLE pass: slp
test.i: In function ‘check_su3’:
test.i:11:5: internal compiler error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
Bug ID: 101242
Summary: Segfault in SLP vectorizor after 2ad71efb5de
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Martin Jambor changed:
What|Removed |Added
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101242
--- Comment #3 from Martin Jambor ---
Profiled LTO bootstrap also fails with a segfault with the same backtrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101398
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #43 from Martin Jambor ---
I have re-tested and re-posted the latest patch series to the mailing list:
- https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568810.html
-
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 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=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=93385
--- Comment #41 from Martin Jambor ---
I reworked the series in order to avoid the biggest objection and posted them
as https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567471.html and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
Martin Jambor changed:
What|Removed |Added
Summary|[9/10/11 Regression]|[9 Regression] Inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
--- Comment #7 from Martin Jambor ---
I am about to test this patch. I think this should be P1 and I would really
like to get this fix to GCC 10.3. Sorry for getting to this so late.
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
--- Comment #6 from Martin Jambor ---
Created attachment 50492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50492=edit
C testcase
C testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
--- Comment #8 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567553.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #29 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #28)
> So fixed for GCC 11 now?
Yes, it should be fixed in GCC 11.
We talked about backporting the patches to GCC 10 with Richi on IRC today and
decided to wait for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #40 from Martin Jambor ---
I have adjusted the patches a little and re-posted them as
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566681.html and
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566682.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99194
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #24 from Martin Jambor ---
*** Bug 99194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #12 from Martin Jambor ---
For the record, I have benchmarked the patches from comment #4 and comment #10
on top of commit 6b1633378b7 (for which I already have unpatched benchmark
results) and the regression of 519.lbm_r compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #25 from Martin Jambor ---
I have proposed a patch for the IPA-CP part on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566333.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98078
--- Comment #6 from Martin Jambor ---
Fixed on master so far (both gcc-10 and gcc-9 branches remain affected).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
--- Comment #5 from Martin Jambor ---
I have not benchmark results from Power, but the reported regression has been
fixed/mitigated on Zens, see:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=275.407.0=397.407.0=294.407.0;
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99951
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=99122
--- Comment #13 from Martin Jambor ---
I think that you want to disable inlining in the case when the callee has a
formal parameter which is a VLA (as opposed to a VLA actual argument of a
call), probably in inline_forbidden_p. When just the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #14 from Martin Jambor ---
Like with the following, which seems to work as far as inlining is concerned,
but the latest Jakub's example ICEs when cloning for IPA-CP :-/ (I am also not
sure if the predicate to identify VLAs is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #4 from Martin Jambor ---
With the patch from comment #3, the following sequence with the problematic
call:
x.1_26 = __builtin_alloca_with_align (_24, 8);
g (WITH_SIZE_EXPR <*x.1_26, _22>, WITH_SIZE_EXPR <*x.1_26, _22>);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #3 from Martin Jambor ---
Looking at how expr.c deals with WITH_SIZE_EXPR, perhaps we should do something
like the following:
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index a710fa59027..cdabeb6bafd 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #6 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #5)
> That could perhaps work for the #c0 testcase where the function actually has
> a non-VL parameter and so garbage in garbage out.
> But would that work also for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90234, which changed state.
Bug 90234 Summary: 503.bwaves_r is 6% slower on Zen1/Zen2 CPUs at -Ofast with
native march/mtune than with generic ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90234
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Bug ID: 99083
Summary: Big run-time regressions of 519.lbm_r with LTO
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #9 from Martin Jambor ---
I will benchmark the patch later this week, just so that we know, but I agree
that reverting the patch and applying it again at the beginning of stage1 is
probably the best.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #17)
> there's variably_modified_type_p (you can pass NULL_TREE for the fndecl)
> which is more to the point. Otherwise it looks reasonable. Does IPA CP
> do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #16 from Martin Jambor ---
For the IPA-CP ICE, I am still running some tests, but I am currently leaning
towards the following. It might in theory disable IPA-CP in some strange K
corner cases (I am searching for those with the
1 - 100 of 556 matches
Mail list logo
