https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #3 from Andi Kleen ---
So what do you want to fix in the kernel?
Use a wrapper for taking the address of the memcpy?
(I hope nothing in gcc would remove such a wrapper)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
--- Comment #5 from Andi Kleen ---
I think it was the method from the info file.
But I can't quite remember. If you cannot reproduce it I guess it's ok to
close. Maybe I made some mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779
Bug ID: 107779
Summary: Support implicit references from inline assembler to
compiler symbols
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Bug ID: 111743
Summary: shifts in bit field accesses don't combine with other
shifts
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #2 from Andi Kleen ---
Okay then it doesn't understand that SHL_signed and SHR_unsigned can be
combined when one the values came from a shorter unsigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #5 from Andi Kleen ---
config/i386/i386.h:#define SLOW_BYTE_ACCESS 0
You mean it doesn't define it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116163
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #13 from Andi Kleen ---
Created attachment 58842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58842&action=edit
add a param to limit BBs for dominator pass
Maybe something like this patch. It adds a check to disable the dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
Attachment #58804|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116264
Bug ID: 116264
Summary: Spurious {NF}s in APX code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Bug ID: 116497
Summary: Need no_caller_saved_registers with SSE support
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #1 from Andi Kleen ---
Disable check for no_caller_saved_registers enforcing non FP.
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index f79257cc764..cec652cc9e6 100644
--- a/gcc/config/i386/i386-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #16 from Andi Kleen ---
Created attachment 59013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59013&action=edit
test case
This test case using Pinski's clobber trick shows the benefit.
If you compile with -O2 -mgeneral-regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #21 from Andi Kleen ---
As HJ pointed out the change is not needed, the compiler DTRT with
no_callee_saved_registers on the callees.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Andi Kleen changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #2 from Andi Kleen ---
Do you have the dump file from tree-vect?
I guess it just doesn't vectorize something here.
The right fix is probably to skip it for sparc, or adjust the vect_int target
test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #4 from Andi Kleen ---
It seems sparc doesn't support comparisons in vectorization?
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c:13:7:
missed: not vectorized: relevant stmt not supported: _13 = _1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Bug ID: 116520
Summary: incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Andi Kleen changed:
What|Removed |Added
Summary|incorrect |Multiple condition lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545
Bug ID: 116545
Summary: Support old style statement attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116599
Bug ID: 116599
Summary: volatile generates unexpected RMW on global
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
--- Comment #8 from Andi Kleen ---
It doesn't even try to convert the switch because of
t.c.179.ifcvt:
Can not ifcvt due to multiple exits
if (loop->num_nodes > 2)
{
/* More than one loop exit is too much to handle. */
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
--- Comment #7 from Andi Kleen ---
Tamas also gave this example in PR115866 which shows the same problem:
short a[100];
int foo(int n, int counter)
{
for (int i = 0; i < n; i++)
{
if (a[i] == 1 || a[i] == 2 || a[i] == 7 || a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
Bug ID: 115091
Summary: Support value speculation in frontend
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
Bug ID: 115255
Summary: sibcall at -O0 causes ICE in df_refs_verify on arm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #4 from Andi Kleen ---
Created attachment 58323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58323&action=edit
hack patch to fix arm sibcalls at -O0
The attached patch makes the test case pass on arm.
- Some of the sibcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #6 from Andi Kleen ---
Created attachment 58324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58324&action=edit
patch to fix arm sibcalls with -O0
Better patch that uses the existing cfun flag for tail calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #7 from Andi Kleen ---
The patch can be even more minimized. The thumb2_reorg change is not needed
because nothing does df_verify() after it (I just noticed it because I added
some extra for debugging). So even though thumb2_reorg br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779
--- Comment #4 from Andi Kleen ---
This whole manual annotation idea (which is equivalent to marking the symbols
global and visible and that is what a large part of the kernel LTO patchkit) is
dead on arrival because the kernel people already re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
Bug ID: 113765
Summary: autofdo: val-profiler-threads-1.c compilation, error:
probability of edge from entry block not initialized
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #1 from Andi Kleen ---
Seems to be a regression, I tested the same setup on gcc 13 and the test passes
there:
55:PASS: gcc.dg/tree-prof/val-profiler-threads-1.c compilation,
-fprofile-generate -D_PROFILE_GENERATE
59:PASS: gcc.dg/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #3 from Andi Kleen ---
-O1 fixes it, so an easy patch would be
diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc
index 63d0c3dc36df..180ed7a8260f 100644
--- a/gcc/auto-profile.cc
+++ b/gcc/auto-profile.cc
@@ -1758,7 +1758,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379
--- Comment #5 from Andi Kleen ---
This bug is about printing a unnecessary message. If your code is actually
miscompiled even with -fno-strict-aliasing set (so it is ignored somewhere) it
is something different and you would need a test case to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
Andi Kleen changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80742
Andi Kleen changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82013
Andi Kleen changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
--- Comment #7 from Andi Kleen ---
I'm not sure how it would speed up the linker if gcc did it. The linker would
still need to do it because there might be matches between different .o files.
Also linker wouldn't know if the compiler supported th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
Bug ID: 115484
Summary: AVX vectorization is limited to 3 comparisons
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #2 from Andi Kleen ---
It would need some heuristic that if the line nearly fills a standard line
length (how defined) don't trigger it. Otherwise people breaking the string due
to line length restrictions might trigger it incorrectl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #3 from Andi Kleen ---
When writing inline assembler an alternative to \n is to use ; as separator
e.g.
asm("movl $1,%eax ; "
"movl %eax,%ebx")
there can be also comment mistake here like
asm("movl $1,%eax # comment ;"
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #6 from Andi Kleen ---
Yes a # check would need to be target dependent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #14 from Andi Kleen ---
Latest patchkit is here, but stalled due to lack of reviewers:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653319.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584
Bug ID: 115584
Summary: Boot strap comparison failure on trunk with
--enable-checking=release
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584
Andi Kleen changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
--- Comment #6 from Andi Kleen ---
As an interesting but irrelevant side comment clang seems to have the same bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 63384, which changed state.
Bug 63384 Summary: scheduler loops on endless fence list with
-fselective-scheduling2 on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Bug ID: 115606
Summary: return slot opt prevents tail calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Andi Kleen changed:
What|Removed |Added
Target|arm-*-* |
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
--- Comment #4 from Andi Kleen ---
Pedantry aside the basic problem is that doloop optimization depends on the
target supporting doloop, but the loop reversal would be useful everywhere.
So there are two options: add doloop to every target of i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
--- Comment #5 from Andi Kleen ---
Also the other problem is that doloop optimization is only for known bounds,
while generic reversal works for unknown too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79465
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #8 from Andi Kleen ---
Ah never mind. I ran it with the wrong option with -O3 it shows the warning.
Unfortunately the run time is very long so it will be difficult to minimize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #10 from Andi Kleen ---
-fno-thread-jumps fixes it, so it's probably a dup of PR109071 (same problem
with a different warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115813
Bug ID: 115813
Summary: missing constant evaluation for vectors
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115813
--- Comment #2 from Andi Kleen ---
Is that the right pattern for the example? It looks different
Enabling match.pd debugging for the scalar version shows:
taddbit.c.034t.ccp1:Applying pattern match.pd:3960, gimple-match.cc:18437
taddbit.c.034t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
Bug ID: 115979
Summary: Implicitly generated C++ calls stop musttail search
early
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
Andi Kleen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
--- Comment #3 from Andi Kleen ---
Doing it in the frontend would require some duplication between C/C++ at least?
I was thinking to just keep searching if has_mustail is set, but was wary of
endless loops walking single basic block precessors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #19 from Andi Kleen ---
Middle/back-end parts are in, still need acks for the C/C++ frontend parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Bug ID: 116019
Summary: Incorrect cannot-tail messages on targets
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83355
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116014
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #1 from Andi Kleen ---
Yes it is known that powerpc (or some flavors of it) has poor tail call support
due to ABI limitations.
Just need to figure out how to skip the test. I guess it needs a better test in
check_effective_target_ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #2 from Andi Kleen ---
Also can you upload the whole log files somewhere? I would like to see what the
output of check_effective_target_struct_tail_call is. It should have caught
some of these problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116087
Bug ID: 116087
Summary: Add optional warning for too large macro expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #6 from Andi Kleen ---
Created attachment 58761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58761&action=edit
Improve test suite tail call checks
This patch should fix it. We must run the test suite tail call probes without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116126
Bug ID: 116126
Summary: vectorize libcpp search_line_fast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #8 from Andi Kleen ---
Patch was reverted, it just made a bunch of tests unsupported.
problems:
- Need unique name for each new test to not confuse the caching
- -O0 tests need to use musttail explictly because the musttail pass
onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Andi Kleen changed:
What|Removed |Added
Attachment #58761|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116970
Bug ID: 116970
Summary: -ftime-report -fdiagnostics-format=sarif-file causes
ICE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #9 from Andi Kleen ---
Yes I guess we should keep better switches at -O1 because machine generated
code may have lot of switches.
I don't think we need perfect clustering? Perhaps there is some heuristic that
is good enough. Maybe j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #11 from Andi Kleen ---
Fix posted here:
https://inbox.sourceware.org/gcc-patches/20241227024559.2224623-1-a...@firstfloor.org/T/#t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
Bug ID: 118211
Summary: tree-vectorize: vectorize input.cc, find_end_of_line
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118251
Bug ID: 118251
Summary: i386: Use carry bits of shifts
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118252
Bug ID: 118252
Summary: i386 should implement CASE_VECTOR_SHORTEN_MODE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118250
--- Comment #2 from Andi Kleen ---
With
--param=switch-lower-slow-alg-max-cases=1
(so using greedy) trunk includes "38" in the first bit cluster, but the LLVM
code is still better. I've seen the dynamic programing algorithm miss clusters
like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #17 from Andi Kleen ---
With the patches now in trunk the overhead for enabling
-Wmisleading-indentation is now ~32% unless --param=file-cache-lines=1 is
used. With the drop behind cache it would be noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #6 from Andi Kleen ---
So the file cache has a window of 100 lines:
static const size_t line_record_size = 100;
The indentation code rereads the line of the guard, body, next statement and
that is all cached if it's all within 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #7 from Andi Kleen ---
Actually in my case where i interrupted and the difference was 60k i think the
problem was that the lexer offset was beyond the 100 lines where the position
is cached, and when that happens the file_cache just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #10 from Andi Kleen ---
My earlier analysis was wrong. The file cache is exactly supposed to avoid
this quadratic case.
But the cache only works if the linemap knows the total number of lines,
otherwise it uses a much slower fallba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #9 from Andi Kleen ---
Created attachment 59954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59954&action=edit
add tunables for file cache
1 - 100 of 147 matches
Mail list logo
