https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622019.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276
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=104024
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 109886, which changed state.
Bug 109886 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type
when compiling gcc.c-torture/compile/pr96796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #9 from Martin Jambor ---
A buildbot run which checked out this revision unfortunately still reports this
problem with UBSAN-bootstrapped compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110183
Bug ID: 110183
Summary: ICE in extract_constrain_insn, at recog.cc:2692 on
s390x-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #7 from Martin Jambor ---
I see, thanks! But I wonder whether it would make sense to commit the simple
fix in the meantime so that the test pass. It is easy to miss new regressions
now when I expect the overall result not to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110038
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #15 from Martin Jambor ---
Oh, because I missed the -DOPACITY in the second command line. The reason for
SRAs creating the repalcement is total scalarization :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #14 from Martin Jambor ---
(In reply to Jan Hubicka from comment #13)
> The only difference between slp vectorization is:
>
> - # _68 = PHI <_5(3)>
> - # _67 = PHI <_11(3)>
> - # _66 = PHI <_16(3)>
> - .r = _68;
> - .g = _67;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
--- Comment #3 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619969.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
--- Comment #9 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619969.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110021
Bug ID: 110021
Summary: [14 Regression] ICE in extract_insn, at recog.cc:2791
on x86_64 with -mavx512vl since
r14-1253-g0368fc54bc11f1
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Bug ID: 109987
Summary: ICE in in rs6000_emit_le_vsx_store on ppc64le with
-Ofast -mno-power8-vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #5 from Martin Jambor ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Aldy Hernandez from comment #2)
> > > If irange::supports_p (TREE_TYPE (arg)) is true, we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
Bug ID: 109932
Summary: ICE in in extract_insn, at recog.cc:2791 on ppc64le
with -mno-vsx
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Bug ID: 109886
Summary: UBSAN error: shift exponent 64 is too large for 64-bit
type when compiling gcc.c-torture/compile/pr96796.c
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 109759, which changed state.
Bug 109759 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type
'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #13 from Martin Jambor ---
*** Bug 109759 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Bug ID: 109825
Summary: [14 Regression] ICE in ix86_widen_mult_cost, at
config/i386/i386.cc:20442 since
r14-666-g608e7f3ab47fe7
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #10 from Martin Jambor ---
The patch from comment #9 does fix the regression. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #8 from Martin Jambor ---
(In reply to Uroš Bizjak from comment #7)
>
> Martin, does this patch fix the runtime regression?
No, unfortunately it does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109813
Bug ID: 109813
Summary: ICE in in extract_insn, at recog.cc:2791 on ARM with
-mflip-thumb
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887
--- Comment #4 from Martin Jambor ---
I believe this has been fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109809
Bug ID: 109809
Summary: ICE in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Bug ID: 109797
Summary: 456.hmmer compiled with -O2 -flto regressed by 15% on
AMD zen3 between r14-487-g6f18f344338b37 and
r14-540-gb7fe38c14e5f1b
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109796
Bug ID: 109796
Summary: 548.exchange2_r compiled with -O2 -flto regressed by
5% on aarch64 between r14-135-gd06e9264b0192c and
r14-192-g636e2273aec555
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
--- Comment #2 from Martin Jambor ---
Likely a duplicate of PR 109788.
I'll close the bug as such if it does not manifest itself over the weekend
ubsan bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
Bug ID: 109759
Summary: UBSAN error: shift exponent 64 is too large for 64-bit
type 'long unsigned int'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
--- Comment #1 from Martin Jambor ---
It is probably me not being able to build the necessary cross compiler
properly, but I cannot build the provided testcase, I always get errors like
the following and then some more:
: note: initializing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607
--- Comment #3 from Martin Jambor ---
(In reply to Richard Biener from comment #0)
> On cfghooks.cc we replace
>
> BIT_FIELD_REF <*this_8(D), 8, 56>
>
An alternative (perhaps for the release branches) would be to avoid SRA if the
parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #12 from Martin Jambor ---
My understanding of comment #2 and #3 is that we end up with what are very
likely bogus BB counts that we should check and perhaps attempt to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14 Regression] -flto |[12 Regression] -flto with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12 Regression] csmith:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #10 from Martin Jambor ---
The problem is actually slightly different, I have just attached a possible fix
to both to PR 107769.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
--- Comment #7 from Martin Jambor ---
Created attachment 54817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54817=edit
potential patch
I am testing the attached patch. I'd like to think about the whole situation a
bit more next week,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
--- Comment #9 from Martin Jambor ---
Most likely a duplicate of PR 107769.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769
--- Comment #6 from Martin Jambor ---
Yes, you identified the correct commit. The same jump function is double
counted (once during iPA-CP and then again during inlining) when we drop
references and so an address reference is replaced with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
--- Comment #9 from Martin Jambor ---
I have proposed the fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614943.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
--- Comment #5 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/ipa-cp.cc.jj 2023-03-14 19:12:19.949553036 +0100
> +++ gcc/ipa-cp.cc 2023-03-29 18:32:34.14423 +0200
> @@ -3117,7 +3117,9 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318
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=107769
Martin Jambor changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #8 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614475.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107670
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=107925
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 107925, which changed state.
Bug 107925 Summary: ICE in update_specialized_profile at gcc/ipa-cp.cc:5082 for
531.deepsjeng_r benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
--- Comment #5 from Martin Jambor ---
Which means that the following (untested) patch might be the correct fix:
diff --git a/gcc/ipa.cc b/gcc/ipa.cc
index 5c15b60a603..c2d94163dc2 100644
--- a/gcc/ipa.cc
+++ b/gcc/ipa.cc
@@ -199,6 +199,11 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
--- Comment #4 from Martin Jambor ---
...and Honza correctly guessed that it is ICF that merges the two functions
(virtual and non-virtual) and that is how we ended up in the situation that the
devirtualizing machinery returns a non-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96059
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #10 from Martin Jambor ---
Fixed on trunk so far, I plan to backport it to GCC 12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Bug ID: 109130
Summary: 464.h264ref regressed by 6.5% on a Neoverse-N1 CPU
with PGO, LTO, -Ofast and -march=native
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #7 from Martin Jambor ---
The situation is that in func_61 we have an unused parameter which
IPA-SRA wants to remove. It's caller constructs the unused parameter
with the following sequence (shortened):
int func_43 (int * p_44)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
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=107925
--- Comment #7 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612506.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
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=108226
--- Comment #2 from Martin Jambor ---
(In reply to Richard Biener from comment #1)
>
> so somehow the restrict qualification pessimizes IPA-CP?! Martin?
>
Well, funny thing. Without restrict, IPA-CP sees (from release_ssa dump):
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
--- Comment #5 from Martin Jambor ---
If you rename main to something else, like bar, and so the calls to f
outside of the loop are not considered cold, you get the GCC 12
behavior. Is this reduced from a real-world problem?
Because on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108800
Bug ID: 108800
Summary: Missed optimization: IPA-SRA keeps a single-field
structure formal parameter even when IPA-CP knows its
contents
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
--- Comment #4 from Martin Jambor ---
I have proposed the fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611978.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
--- Comment #3 from Martin Jambor ---
What happens is that ipa_param_body_adjustments::modify_call_stmt
is confused by the IPA-CP produced scalar constant where it expects a
structure containing just one field of the corresponding type.
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #13 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611194.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108629
Bug ID: 108629
Summary: 549.fotonik3d_r regresses 15-24% at -O2 -flto
-march=x86-64-v3 since r13-1203-g038b077689bb53
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101296, which changed state.
Bug 101296 Summary: Addition of x86 addsub SLP patterned slowed down 433.milc
by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481
--- Comment #17 from Martin Jambor ---
Looking LNT (and excluding machines which are no longer active), the worst
regression is now 4% and that only at -O2 -Ofast. Probably not a very high
priority then (do we want to close this?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151
--- Comment #3 from Martin Jambor ---
In January 2022 I see 9% regression on zen2, 8% regression on zen3 and
CascadeLake and 7% on zen4 (compared to gcc 7). I no longer track
zen1. LNT largely confirms these observations although it tracks -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158
--- Comment #4 from Martin Jambor ---
(In reply to Richard Biener from comment #3)
> it looks like the testcase no longer shows the issue(?) but the code in IPA
> SRA didn't really change here
I have fixed quadratic behavior in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469
--- Comment #19 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #16)
> Martin, is that a real fix for this or it just went latent?
Not a fix, the bug mst be latent. But it is surprising so I'll have a look
what happened too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #14 from Martin Jambor ---
Honza, what remains to be done here (if anything)?
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.
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=745.467.0=777.467.0=687.467.0;
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=104122
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=105275
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
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=94369
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=711.337.0=740.337.0=694.337.0;
201 - 300 of 550 matches
Mail list logo
