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 @@ se
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 Ma
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=97578
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
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 create_clone
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 in
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=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=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
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=9781
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
non-NU
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 b28c78eeab
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
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Since
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 f
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 _GLOBAL__sub_I_t
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=80689
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jamborm at gcc
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=47059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
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=58243
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #2 from Martin Jambor ---
I'll have a look
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=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 d
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=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
ev
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 #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=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 propo
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=97588
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=94373
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=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|R
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ubizjak at gmail dot com
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
On AMD Zen2 CPUs, 519.lbm_r is 62.12
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=95343
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
--- a/gcc/tree-inl
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>);
__buil
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 #c
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 cal
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 bes
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&R
corner cases (I am searching for those with the tes
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 things
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 wit
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/pipermail/gcc-patches/2021-April/568811.h
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
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100491
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #3 from Martin Jambor ---
Mine.
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=100453
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
--- 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
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
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Since commit 2ad71efb5de (fix BB reduc permute
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: S
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=108110
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
> dup of PR108445?
Looks like it is, Bugzilla search has failed me again (but I've never been good
at it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108445
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 108444, which changed state.
Bug 108444 Summary: ICE: invalid address operand in mem_ref when LTO building
523.xalancbmk_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108444
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108445
--- Comment #7 from Martin Jambor ---
I can confirm that xalancbmk_r is LTO-buildable again too. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360
--- Comment #3 from Martin Jambor ---
LNT can still see this, on the zen2 and zen3 machine at least:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=700.337.0&plot.1=711.337.0&plot.2=740.337.0&plot.3=694.337.0&;
https://lnt.opensuse.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94369, which changed state.
Bug 94369 Summary: 505.mcf_r is 6-7% slower at -Ofast -march=native with
PGO+LTO than with just LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104125
--- Comment #5 from Martin Jambor ---
This still exists but it is a zen2 oddity. The zen3, zen4 and cascade-lake
machines I looked at this month don't exhibit this behavior (or at least I
don't see an obvious regression).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 94373, which changed state.
Bug 94373 Summary: 548.exchange2_r run time is 16-35% worse than GCC 9 at -O2
and generic march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90128, which changed state.
Bug 90128 Summary: 507.cactuBSSN_r is 9-11% slower at -Ofast and native
march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104122, which changed state.
Bug 104122 Summary: On Zen3, 510.parest_r (built with -Ofast) is faster with
generic than with native ISA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94410
--- Comment #3 from Martin Jambor ---
This is still the case, as can be seen on LNT (GCC 9 is the dot in the left
bottom corner):
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=690.467.0&plot.1=745.467.0&plot.2=777.467.0&plot.3=687.467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360
--- Comment #5 from Martin Jambor ---
Well, if the current behavior is a good one (I have not looked at how
size/performance trade-off works out) then I am also fine declaring this bug
invalid.
1701 - 1800 of 2365 matches
Mail list logo
