https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #6 from Sam James ---
Can you bisect further back with -param=vrp2-mode=ranger, to force ranger
before it was the default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792
--- Comment #15 from Sam James ---
Roger, is this one ready to backport to releases/gcc-13 so we can pick it up
easily downstream via the branch snapshots, or do you want to let it bake on
trunk a bit longer? Cheers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110926
--- Comment #4 from Sam James ---
Created attachment 55699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55699=edit
reduced.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110926
--- Comment #3 from Sam James ---
Created attachment 55698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55698=edit
reduced.i
Reduced version attached, not cleaned it up yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110926
--- Comment #2 from Sam James ---
Created attachment 55697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55697=edit
matmul_i1.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110926
Bug ID: 110926
Summary: [14 regression] Bootstrap failure (matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0
type 'i' or 'n', have 'w' (rtx const_int) in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #10 from Sam James ---
(In reply to Sam James from comment #9)
> (In reply to Shaohua Li from comment #8)
> > I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
>
> Could you try bisect further back with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #9 from Sam James ---
(In reply to Shaohua Li from comment #8)
> I tried to bisect it and I bisected it to r12-4871-g502ffb1f389
Could you try bisect further back with -param=vrp2-mode=vrp, or does it work
fine with that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280
--- Comment #16 from Sam James ---
Prathamesh, could you cherry-pick this on to the releases/13 branch please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #22 from Sam James ---
Thanks for your help.
We've had this in production since 26th May and no complaints (but a lot of
happy customers who couldn't build 12 or earlier 13 versions):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022
--- Comment #6 from Sam James ---
(In reply to Martin Liška from comment #5)
> Yes, -ggdb3 seems to me like a reasonable solution. Note you can always
> strip the debuginfo into a separate file.
This doesn't really work for us, as building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673
--- Comment #2 from Sam James ---
Created attachment 55548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55548=edit
reduced.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673
--- Comment #1 from Sam James ---
Created attachment 55547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55547=edit
test_unit_entropy.c.i
This is what cvise popped out, it's borderline invalid though, so let me touch
it up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673
Bug ID: 110673
Summary: [14 regression] ICE when buliding opus (internal
compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617
Sam James changed:
What|Removed |Added
CC||bugzilla at tecnocode dot
co.uk,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Bug 84402 depends on bug 54179, which changed state.
Bug 54179 Summary: please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Sam James changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110579
--- Comment #2 from Sam James ---
Could you give us a backtrace with -ggdb3 when it aborts at runtime?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110553
Bug ID: 110553
Summary: -fsanitize=undefined needs -latomic on
powerpc-unknown-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110489
Bug ID: 110489
Summary: Slow building virtual.c.i from p11-kit
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110465
Bug ID: 110465
Summary: [14 regression] ICE when building openssl with new
vector_type checking
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #10 from Sam James ---
(In reply to Jonathan Wakely from comment #9)
> It seems we should be using loff_t here.
For the benefit of the bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110461
--- Comment #2 from Sam James ---
Created attachment 55417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55417=edit
reduced.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #7 from Sam James ---
Oh, duh, it's libstdc++. I'm not sure there's an alternative to typedefing it
then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #4 from Sam James ---
(In reply to Jonathan Wakely from comment #2)
> The system call is defined in terms of off64_t. What type does musl use for
> copy_file_range(2)?
/usr/include/unistd.h:197:ssize_t copy_file_range(int, off_t *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #3 from Sam James ---
Looks like we already AC_SYS_LARGEFILE in libstdc++-v3/configure.ac, so this
should be as simple as just using off_t instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #1 from Sam James ---
Created attachment 55415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55415=edit
build.log.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
Bug ID: 110462
Summary: [14 regression] Build failure with musl-1.2.4
(filesystem/ops-common.h:377:5: error: 'off64_t' was
not declared in this scope; did you mean 'off_t'?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110461
Bug ID: 110461
Summary: [14 regression] ICE when building openh264 with new
vector_type checking
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110440
--- Comment #3 from Sam James ---
I've hit it with another package (basis_universal) but the ICE looks identical
and it's C++ so I won't worry about reducing it unless someone asks me to.
```
during GIMPLE pass: vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110440
--- Comment #2 from Sam James ---
Created attachment 55406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55406=edit
reduced.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110440
--- Comment #1 from Sam James ---
gcc -O3 -c ... is enough to repro.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110440
Bug ID: 110440
Summary: [14 regression] ICE when building pixman
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #9 from Sam James ---
Yes - primarily from znver4 users who build with -march=native (or
-march=znver4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #7 from Sam James ---
We keep getting quite a few reports of this downstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #2 from Sam James ---
Created attachment 55390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55390=edit
pixman-matrix.c.i
I think I've hit the same thing building pixman.
```
# gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332
--- Comment #5 from Sam James ---
Created attachment 55379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55379=edit
reduced.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332
--- Comment #1 from Sam James ---
g++ -O3 -c ... is enough to repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110332
Bug ID: 110332
Summary: [14 regression] ICE in dominated_by_p when building
LLVM with -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325
Sam James changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325
--- Comment #6 from Sam James ---
Created attachment 55374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55374=edit
/proc/cpuinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325
--- Comment #3 from Sam James ---
Host compiler is:
```
gcc (Gentoo 14.0.0 p, commit f9de5c24b9a6172d48786289035eed8f947c04c1) 14.0.0
20230616 (experimental) a371a639b76f1bdcd7a957f400b5a7c0faf30a15
Copyright (C) 2023 Free Software Foundation,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325
--- Comment #1 from Sam James ---
Created attachment 55373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55373=edit
build.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325
Bug ID: 110325
Summary: [14 regression] Build failure on arm64
(libiberty/physmem.c:83:1: error: ‘+nofp’ feature
modifier is incompatible with the use of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770
--- Comment #8 from Sam James ---
(See the thread at
https://inbox.sourceware.org/gcc-patches/6027e3bb-99f9-573b-ff5e-ea1a48882...@acm.org/.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104271, which changed state.
Bug 104271 Summary: [12 Regression] 538.imagick_r run-time at -Ofast
-march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #17 from Sam James ---
Thank you Vladimir! I appreciate the time both of you are spending on
alternative platforms for bugs like these.
Also, Vladimir, if you want to continue to use the machine after this, if you
ever have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
--- Comment #5 from Sam James ---
Created attachment 55258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55258=edit
reduced.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
--- Comment #2 from Sam James ---
$ /var/tmp/portage/sys-devel/gcc-14.0.0_pre20230604/work/build/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230604/work/build/./gcc/xgcc
Target: x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
--- Comment #1 from Sam James ---
march is znver2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
Bug ID: 110120
Summary: [14 regression] Failed bootstrap on
x86_64-pc-linux-gnu (locale_facets.tcc:588:7: internal
compiler error: RTL check: expected elt 0 type 'e' or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #15 from Sam James ---
Okay. I couldn't hit it on some native machines until I rebuilt with more
checking, but maybe that was a fluke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
Sam James changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110110
Sam James changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110110
--- Comment #5 from Sam James ---
Oh, I bet you're right. Oops.
I'll let the bisect run anyway, as I need to jump through all the hoops to send
V8 a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110110
--- Comment #1 from Sam James ---
It doesn't seem to be resolving to the STL template which takes an iterator,
given the error & warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110110
Bug ID: 110110
Summary: [14 regression] nodejs/v8 fails to compile with error:
cannot convert
‘std::vector::iterator’ to ‘const char*’
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #13 from Sam James ---
By the way, I think this needs --enable-checking=rtl, which is maybe why you
couldn't hit it before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #12 from Sam James ---
(Vladimir (and anyone else interested): For bugs like this, you're welcome to
use gentoo's testing hardware if desired. Just email me an SSH key.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #16 from Sam James ---
(In reply to Richard Biener from comment #9)
> My suggestion is to not enable -fipa-pta if you hit such issue or in general
> if you don't know it pays off with a good runtime performance boost.
Many thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #4 from Sam James ---
I know what the option does, but:
1. It's substantially slower in 12/13/14, with or without checking. If that's
expected, that's fine, but someone has to say if it is.
2. With default checking (=release) on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Sam James changed:
What|Removed |Added
Keywords||compile-time-hog
--- Comment #2 from Sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #1 from Sam James ---
I let perf spin for a while and got this w/ 13:
```
$ perf record gcc-13 -O2 -fipa-pta -c packet-rnsap.c.i
[^C'd after ~2 minutes]
$ perf report
43.18% cc1 cc1 [.]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Bug ID: 109983
Summary: [12/13/14 regression] Wireshark compilation hangs with
-O2 -fipa-pta
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #20 from Sam James ---
When I looked at it, I think I got it to apply to 13 with no hassle and it
seemed to work okay, but I didn't test it that hard.
It's a considerable win so even if not backported upstream, if you think it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85734
--- Comment #6 from Sam James ---
Paul noted at
https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00139.html that this
seems to have come back, but interestingly, this bug never got closed in the
first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #17 from Sam James ---
Is there by chance a workaround we can apply for this downstream (some flag)?
It prevents building Chromium on arm64 for us w/ gcc unfortunately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
--- Comment #13 from Sam James ---
the OOB read seems to go away with --enable-checking=yes,rtl,extra (previously
had --enable-checking=release)...? (at least for 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
--- Comment #10 from Sam James ---
fwiw, on glibc, I don't get the oob read w/ valgrind but still the ICE as
you've already found.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #16 from Sam James ---
Filed my musl one as PR109868, sorry for clogging up this one!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
--- Comment #2 from Sam James ---
Created attachment 55089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55089=edit
clock.ii (reduced)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
--- Comment #1 from Sam James ---
Created attachment 55088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55088=edit
clock.ii.orig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
Bug ID: 109868
Summary: [13/14 regression] ICE: segmentation fault when
building small C++ program
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #14 from Sam James ---
(In reply to Alexander Monakov from comment #13)
> The 128KB stack size is for *secondary* threads on musl (i.e. those created
> via pthread_create). The main thread has the same stack as on glibc (GCC
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Sam James changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379
--- Comment #3 from Sam James ---
This is a bit of (not entirely, but a lot of) what I was reaching for in
PR109835. I knew there was a ppc64 example in my head but I couldn't find it.
It's also a good argument for just doing it entirely for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #4 from Sam James ---
(In reply to Eric Gallager from comment #3)
> I thought that there was already a separate bug for this, but it turns out
> that I was thinking of bug 87379, which is for something different...
Good catch. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
--- Comment #1 from Sam James ---
Created attachment 55075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55075=edit
GlyphCache.cpp.ii (reduced)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
Bug ID: 109840
Summary: internal compiler error: in expand_fn_using_insn, at
internal-fn.cc:153 when building graphite2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #8)
> Created attachment 55071 [details]
> graphite2-GlyphCache.cpp.ii (maybe related)
I guess this is really the same given the operations it's doing (its own
bswaps).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #8 from Sam James ---
Created attachment 55071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55071=edit
graphite2-GlyphCache.cpp.ii (maybe related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #2 from Sam James ---
Okay, fair point, I gave examples but not *motivating* examples.
I have some non-harmless examples:
1.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1
(a nasty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #6 from Sam James ---
Created attachment 55069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55069=edit
reduced.ii
I might reduce the graphite2 one for fun just to see how different it is but no
promises.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
Bug ID: 109835
Summary: -Wincompatible-function-pointer-types as a subset of
-Wincompatible-pointer-types?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #1 from Sam James ---
The *other* main issue I have is with graphite2:
```
FAILED: src/CMakeFiles/graphite2.dir/GlyphCache.cpp.o
/usr/bin/aarch64-unknown-linux-gnu-g++ -DGRAPHITE2_NTRACING -Dgraphite2_EXPORTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Bug ID: 109834
Summary: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (ssa_name) in
gimple_simplify_191 when building harfbuzz
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109765
--- Comment #6 from Sam James ---
Report is at https://marc.info/?l=gmp-bugs=168367093126416=2. I ended up
sending it a few times because I've had mail delivery problems before and I
didn't realise the list was moderated even for subscribers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109794
Sam James changed:
What|Removed |Added
Attachment #55034|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109794
--- Comment #1 from Sam James ---
Created attachment 55035
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55035=edit
evaluate_prg_hwy.ii.xz (13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109794
Bug ID: 109794
Summary: Compile time hog when building chromium on
aarch64-unknown-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661
--- Comment #10 from Sam James ---
Could you post the backport here (or chuck it on the 13 branch) so we could
pull it in for gentoo? thanks
801 - 900 of 1001 matches
Mail list logo
