https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #10 from Alexander Monakov ---
Yeah, I would expect compare_operand to be the proper place for a fix, not its
callers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
--- Comment #5 from Alexander Monakov ---
Thanks, here's a variant of the small testcase that fails on gcc-14 too, just
needed to make the integer field the first in the struct:
struct s {
int i[2];
float f[2];
double d;
};
void f(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
Bug ID: 117926
Summary: [15 Regression] emits MMX from autovectorized GIMPLE
without emms at -O2
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #4 from Alexander Monakov ---
The code in comment #3 is invalid: siglongjmp is called when the state saved in
env is no longer valid: plat_setjmp has returned (and the stack slot where its
return address is stored is overwritten).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117421
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #22 from Alexander Monakov ---
*** Bug 117532 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
--- Comment #2 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #1)
> So if the tail-call uses [[musttail]] the alternative 3 should be "fine"?
Yes, plus annotating the callees that return twice with the attribute is still
require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117469
Bug ID: 117469
Summary: returns_twice on defined functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #6 from Alexander Monakov ---
compare_operand is used in compare_asm_inputs_outputs, so this is broken too:
void foo32(void) {
asm("" :: "r"(-1));
}
void foo64(void) {
asm("" :: "r"(-1LL));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #1 from Alexander Monakov ---
Created attachment 59528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59528&action=edit
executable testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
Bug ID: 117432
Summary: [11/12/13/14/15 Regression] IPA ICF disregards types
of variadic arguments
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
--- Comment #12 from Alexander Monakov ---
On IRC Jakub mentioned gcc_assert (token() == TYPEDEF) in gengtype and Richi
further noted
tree-ssa-loop-ivopts.cc:gcc_assert (use->op_p = gimple_call_arg_ptr (call, 0));
cgraph.cc: gcc_assert (++edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #2)
> Alternatively,
> changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.
^
I meant 'if (o.i ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #2 from Alexander Monakov ---
Amazing bug. Note that it depends on high-order bits of return address
overwriting o.i, so may need -no-pie -fno-pie to reproduce. Alternatively,
changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #15 from Alexander Monakov ---
No, I didn't do older AMDs (btver2 & bdver3) and newer AMD (znver4) regressed
this once again. Here's the current picture of top 10:
nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116947
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #11 from Alexander Monakov ---
> It only handles switch statements, not computed gotos.
Oh, right, apologies for misunderstanding your question like that. For computed
gotos it is indeed not so easy, especially if there is more than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
--- Comment #9 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #8)
> Is there any pointer how to implement this instead?
It may be sufficient to change
(define_insn "@tablejump"
[(set (pc)
(match_operand:P 0 "register_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116483
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #12 from Alexander Monakov ---
Thanks. It's probably nicer to deduplicate computation of required padding to a
common header (libcpp/internal.h), I'll send a patch to that effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #9 from Alexander Monakov ---
Okay, if you take the addition and the branch from the inlined variant:
addl %eax, %edx
je .L3
and add a 'test' instruction:
addl %eax, %edx
test %edx, %edx
je .L3
then Valgrind doesn't complain. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #8 from Alexander Monakov ---
Thanks for the reference, but it doesn't help. Something more subtle is going
on, because placing the shift-add combo in a separate function makes Valgrind
properly compute known bits even without the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #6 from Alexander Monakov ---
As for Valgrind false positive, it handles this SSSE3 code really well and
misses the key point by a very narrow margin. We have
found = m1 + (m2 << 16);
where both m1 and m2 hold 16-bit masks from p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #3 from Alexander Monakov ---
David, thanks for Cc'ing me and for running Valgrind builds!
Richi, I'll check in more detail later today, I think we should unbreak
Valgrind builds ASAP by initializing padding under #ifdef
ENABLE_VALG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #15 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Alexander Monakov from comment #13)
> > fldt does not convert (otherwise there's no way to spill/reload x87
> > registers).
>
> Doesn't it st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #26 from Alexander Monakov ---
(In reply to Richard Biener from comment #24)
>
> That's because of -fno-vect-cost-model, it wouldn't be vectorized otherwise.
Thanks, I forgot. The testcase in PR 106902 was vectorized at plain -O3 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #23 from Alexander Monakov ---
I suggest it to close this a dup of PR 106902 if there are no better ideas.
By the way, in both cases SLP introduces vectors in a loop where scalar
computations it's attempting to replace are not elimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #22 from Alexander Monakov ---
Similar to the RawTherapee issue, SLP opportunities are created by predcom, so
either -fno-predictive-commoning or -fno-tree-slp-vectorize avoids numerical
runaway on the small testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #20 from Alexander Monakov ---
Sam, can you provide more context? It seems there is no downstream bugreport?
How does the alleged miscompilation manifest?
Note that effects of interplay of fp-contract=fast and vectorization can be
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #23 from Alexander Monakov ---
(In reply to Sergei Trofimovich from comment #22)
> Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
> `%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #20 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #19)
> If we guarantee that we never constant fold FIX/UNSIGNED_FIX with
> -ftrapping-math (we shouldn't, as the exceptions should be raised), then
> using FIX/UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #18 from Alexander Monakov ---
No, allowing value-changing transformations under -ftrapping-math is really not
appropriate. Invoking the intrinsic on a large floating-point value is not UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
--- Comment #4 from Alexander Monakov ---
Like this:
pandxmm1, XMMWORD PTR .LC0[rip]
movaps XMMWORD PTR [rsp-40], xmm0
xor eax, eax
xor edx, edx
movaps XMMWORD PTR [rsp-24], xmm1
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960
Bug ID: 114960
Summary: [12/13/14/15 Regression] fails to clean up vector
casts
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #4 from Alexander Monakov ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:
asm volatile("" : "=m"(buf));
This cannot be reordered against accesses to volatile va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #21 from Alexander Monakov ---
It is possible to reduce gcc_qsort workload by improving the presorted-ness of
the array, but of course avoiding quadratic behavior would be much better.
With the following change, we go from
261,2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #20 from Alexander Monakov ---
(note that if you uninclude the testcase and compile with -fno-exceptions it's
much faster)
On the smaller testcase from comment 14, prune_unused_phi_nodes invokes
gcc_qsort 53386 times. There are two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #10 from Alexander Monakov ---
Indeed, but OTOH according to bug 84402 comment 58 it caused a noticeable hit
on gimple-match.cc compilation:
733a1b777f16cd397b43a242d9c31761f66d3da8 13th January 2023
sched-deps: do not schedule pseu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #8 from Alexander Monakov ---
If we want to get rid of the compilation time regression sooner rather than
later, I can suggest limiting my change only to functions that call setjmp:
diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
Alexander Monakov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #3 from Alexander Monakov ---
The first attachment is empty (perhaps you made a non-recursive archive when
you meant to recursively zip a directory).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
--- Comment #28 from Alexander Monakov ---
The bug is about the issue of lacking diagnostics, it should be fine to make
note of various approaches to remedy the problem in one bug report.
(in any case, all discussion of the Valgrind-based approa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113293
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #9 from Alexander Monakov ---
... as does inserting a nop before the compare ¯\_(ツ)_/¯
--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
+++ d.out.ltrans0.ltrans.s 2023-12-01 18:53:04.909438690 +0300
@@ -743,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #8 from Alexander Monakov ---
Thanks, I can reproduce it. It is pretty tricky though. For instance, just
swapping the mov and the compare is enough to make it fast:
--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Bug ID: 112701
Summary: wrong type inference for ternary operator in
preprocessing context
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
--- Comment #2 from Alexander Monakov ---
Sorry, even though GCC's limits.h is installed under include-fixed, it is
generated separately, not by the generic fixincludes mechanism. I was confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #13 from Alexander Monakov ---
> Then there is the MULT_EXPR x * x case
This is PR 111701.
It would be nice to clarify what "nonnegative" means in the contracts of this
family of functions, because it's ambiguous for NaNs and negat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82242
--- Comment #5 from Alexander Monakov ---
The small testcase from comment 3 is now improved on trunk, possibly thanks to
work in PR 110215.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Bug ID: 111884
Summary: unsigned char no longer aliases anything under
-std=c2x
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #11 from Alexander Monakov ---
(In reply to Hongtao.liu from comment #10)
> > indeed (but I believe it did happen with Alder Lake already, by accident,
> > with AVX512 on P-cores but not on E-cores).
>
> AVX512 is physically fused o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #9 from Alexander Monakov ---
(In reply to Arsen Arsenović from comment #8)
> indeed (but I believe it did happen with Alder Lake already, by accident,
> with AVX512 on P-cores but not on E-cores).
AFAIK on those Alder Lake CPUs you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #5 from Alexander Monakov ---
I think it's similar to attempting -march=native under distcc, which is already
warned about on Gentoo wiki: https://wiki.gentoo.org/wiki/Distcc
The difference here is that Intel so far decided to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #7 from Alexander Monakov ---
No backport for gcc-13 planned?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #3 from Alexander Monakov ---
Sorry, the second half of my comment is confusing. To clarify, ASan works fine
for TLS data (the compiler knows that TLS base is at fs:0; libsanitizer uses
some hacks to initialize shadow for TLS anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701
Bug ID: 111701
Summary: [11/12/13/14 Regression] wrong code for
__builtin_signbit(x*x)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #11 from Alexander Monakov ---
(In reply to Richard Biener from comment #10)
> And this conservatively has to apply to all FP divisions where we might infer
> "nonnegative" unless we can also infer !zerop?
Yes, I think the logic in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111210
--- Comment #4 from Alexander Monakov ---
The testcase is small enough to notice the issue by inspection.
Note that you get the "expected" answer with -fno-strict-aliasing, and as
explained in https://gcc.gnu.org/bugs/ it is one of the things y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111210
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #6 from Alexander Monakov ---
Thanks.
i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?
1 - 100 of 417 matches
Mail list logo
