https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63413
Bug ID: 63413
Summary: cpp trying to expand "vector" word in commented line
in fortran file on power8
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity:
;<< should be '3*2', i.e. '6'.
> extu.w r2,r2
> add r2,r5
> .L3:
> dt r4
> bf/s.L4
> add #8,r1
> .L12:
> rts
> mov r5,r0
> .L15:
> .align 2
> .L14:
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #5 from Piotr Dziwinski ---
(In reply to Jonathan Wakely from comment #4)
> tr1::tuple doesn't support perfect-forwarding or move semantics
>
> tr1::tuple doesn't support uses-allocator construction
>
> tr1::tuple doesn't support 'f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #4 from thopre01 at gcc dot gnu.org ---
I detect no noticeable difference when bootstrapping gcc with or without the
patch so I think we're in for a fix. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
--- Comment #1 from Doug Gilmore ---
Created attachment 33617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33617&action=edit
Modified version where type casts are modified.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
Bug ID: 63412
Summary: aliasing issue exposed by inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #48 from Oleg Endo ---
(In reply to Oleg Endo from comment #47)
> Created attachment 33615 [details]
> reduced CSiBE /libpng-1.2.5 test
>
> I've tried compiling CSiBE (-m4 -ml). This is a stripped down pngrutil.c
> which crashes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #47 from Oleg Endo ---
Created attachment 33615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33615&action=edit
reduced CSiBE /libpng-1.2.5 test
I've tried compiling CSiBE (-m4 -ml). This is a stripped down pngrutil.c which
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #46 from Oleg Endo ---
newlib 1.2.0 now builds without errors here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
Oleg Endo changed:
What|Removed |Added
CC||amker.cheng at gmail dot com,
L15:
.align 2
.L14:
.long _OAM3+3
.size _test2, .-_test2
.ident "GCC: (GNU) 4.9.2 20140929 (prerelease)"
Disabling ivopt with '-fno-ivopts' produces correct code:
_test2:
tst r4,r4
bt .L12
mov #0,r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
François Dumont changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #12 from François Dumont ---
Author: fdumont
Date: Mon Sep 29 21:22:17 2014
New Revision: 215693
URL: https://gcc.gnu.org/viewcvs?rev=215693&root=gcc&view=rev
Log:
2014-09-29 François Dumont
PR libstdc++/62313
* include/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #5 from frankhb1989 at gmail dot com ---
BTW, what if the clock_gettime call failed? The current implementation does
nothing about error handling... (Though for QPC on Windows it should rarely
fail for machines within a decade.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #9 from Dominique d'Humieres ---
For the record the test gfortran.dg/typebound_operator_3.f03 also failed with
-O1 and -m64 (see https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00226.html).
This is fixed by the patch at
https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> What libstdc++ is doing is sensible, why is the realtime clock so much
> coarser than the monotonic clock on mingw-w64?
It is not always true tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
--- Comment #2 from Brooks Moses ---
Ping? Any updates on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl ---
(In reply to Jan Hubicka from comment #22)
> > > Doing it at same approximately the same place as loop header copying
> > > seems to
> > > make most sense to me. It benefits from early cleanups and DCE definitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #2 from Itay Perl ---
Yes, I am certain.
1. Replacing the minus sign with a plus sign results in the same code
(including the constant)
2.
>>> struct.unpack('I', struct.pack('f', 100))[0]
1120403456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #8 from Jiong Wang ---
(In reply to Pat Haugen from comment #6)
> (In reply to Jiong Wang from comment #5)
> > we need to check the following
> >
> >else if (GET_CODE == CLOBBER
> > || GET_CODE (x) == USE
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #7 from Jiong Wang ---
(In reply to Pat Haugen from comment #6)
> (In reply to Jiong Wang from comment #5)
> > we need to check the following
> >
>
> r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark
> 254.gap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #41 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Mon Sep 29 18:40:57 2014
New Revision: 215690
URL: https://gcc.gnu.org/viewcvs?rev=215690&root=gcc&view=rev
Log:
PR target/61407
* config/darwin-c.c (version_as_ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #1 from Andrew Pinski ---
Are you sure 1120403456 does not encode -100.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410
Bug ID: 63410
Summary: [Regression] pass_instances.def is not installed
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
cbaylis at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #3 from Jonathan Wakely ---
What libstdc++ is doing is sensible, why is the realtime clock so much coarser
than the monotonic clock on mingw-w64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #34 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 17:07:47 2014
New Revision: 215686
URL: https://gcc.gnu.org/viewcvs?rev=215686&root=gcc&view=rev
Log:
2014-09-29 Charles Baylis
Backport from mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #33 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Mon Sep 29 16:47:31 2014
New Revision: 215685
URL: https://gcc.gnu.org/viewcvs?rev=215685&root=gcc&view=rev
Log:
2014-09-29 Charles Baylis
Backport from mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
--- Comment #6 from Jan Hubicka ---
> We could also make $0 a not legitimate constant on x86... (and undo that late
> with a peephole2)
I tried that in 90's. At that time it increased register pressure and was not
win...
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #22 from Jan Hubicka ---
> > Doing it at same approximately the same place as loop header copying seems
> > to
> > make most sense to me. It benefits from early cleanups and DCE definitly
> > and
> > it should enable more fun with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Which of macros are defined on mingw-w64?
>
> Preprocessing this should tell you
>
> #include
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
> #ifdef _GL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270
--- Comment #6 from Uroš Bizjak ---
(In reply to marxin from comment #5)
> Author: marxin
> Date: Mon Sep 22 09:39:20 2014
> New Revision: 215451
>
> URL: https://gcc.gnu.org/viewcvs?rev=215451&root=gcc&view=rev
> Log:
> PR lto/63270 - new test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
Bug ID: 63409
Summary: [5 Regression] FAIL: g++.dg/lto/pr63270
cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2
-Wno-odr -fno-linker-plugin
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #5 from David Kredba ---
Link command to produce a binary, Boost is 1.56:
x86_64-pc-linux-gnu-g++ -flto=4 -fuse-linker-plugin -O2 -g -save-temps
-march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed
-Wl,-O2 -Wl,--s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #4 from David Kredba ---
Created attachment 33613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33613&action=edit
all ii files compressed by 7zip
tar.bz2 file size was 8.2 MiB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #5 from Jakub Jelinek ---
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on {x86_64,i686,armv7hl,aarch64}-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Bug ID: 63408
Summary: GCC emits incorrect FMA instruction
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
Manuel López-Ibáñez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #4 from Jonathan Wakely ---
tr1::tuple doesn't support perfect-forwarding or move semantics
tr1::tuple doesn't support uses-allocator construction
tr1::tuple doesn't support 'final' classes
tr1::tuple doesn't have correct exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to Jason Merrill from comment #22)
> It could be done specifically for uses in mem-initializers by walking the
> initializer in perform_mem_init to look for any references to members that
> h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #3 from Piotr Dziwinski ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Piotr Dziwinski from comment #1)
> > I would also second the proposal to fix this issue by implementing flat
> > version of std::tuple. Perhaps t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #3 from David Kredba ---
objdump -d produced 24 and 30 MiB files and diff -u is 50 MiB, diff 55 MiB.
Even 7z can compress it to uploadable size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407
--- Comment #2 from David Kredba ---
Created attachment 33611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33611&action=edit
xsd files with folder structure
isable-isl-version-check
Thread model: posix
gcc version 4.10.0-alpha20140928 20140929 (experimental) [trunk revision
215679] (Gentoo 4.10.0_alpha20140928)
fails the same way:
terminate called after throwing an instance of 'Cult::MM::Absent'
what(): N4Cult2MM6AbsentE
/bin/sh: řáde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #11 from boger at us dot ibm.com ---
On ppc64 BE, the call to make_code_func_reference returns the function pointer
in the .opd and not the actual address of the function. That is what causes
the failures with this patch
https://gcc.g
cc version 4.9.2-alpha20140928 20140929 (prerelease) [gcc-4_9-branch revision
215679] (Gentoo 4.9.2_alpha20140928)
C(XX)FLAGS "-flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2"
I am going to try version 5 from svn.
Should I post disassemble diff output or how to continu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
--- Comment #15 from dave.anglin at bell dot net ---
On 29-Sep-14, at 2:43 AM, zhenqiang.chen at arm dot com wrote:
> Please try the attached patch. If it works, I will run all tests and
> send it
> for community review.
The patch appears to f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63262
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33610&action=edit
proof-of-concept patch
Using this proof-of-concept patch, we manage to get the desired code. The patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #5 from Jiong Wang ---
we need to check the following
else if (GET_CODE == CLOBBER
|| GET_CODE (x) == USE
|| GET_CODE (x) == ASM_INPUT)
I will post the fix after pass x86 bootstrap and regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
--- Comment #2 from Jakub Jelinek ---
I'd say it would still be worthwhile, if it was just a matter of XFAILing a few
testcases, because the number of false positives is more important, if the
warning is too unreliable, people just will ignore it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
--- Comment #1 from Richard Biener ---
I think we have similar dups elsewhere (warning for last unrolled iteration
which is never executed).
My previous naiive attempts dropped warnings from VRP2 and only warn from
VRP1 (but that regresses some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395
--- Comment #12 from Richard Biener ---
You can also try -fexcess-precision=standard on Cygwin, -mpc64 might not be
implemented there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386
--- Comment #6 from Richard Biener ---
Please provide preprocessed source of the file crashing the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #4 from Jiong Wang ---
sorry for causing the trouble.
the reason might be the "flag" is an implified register while it's not take
into account in current shrink-wrap reg read/write analysis.
I will revert my patch temperarily if I c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63383
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #10 from Richard Biener ---
(In reply to Andi Kleen from comment #9)
> Any progress on fixing the test case, so that this can be finally fixed?
I have no idea how to do that without making the testcase test sth different.
We could of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
--- Comment #5 from Richard Biener ---
We could also make $0 a not legitimate constant on x86... (and undo that late
with a peephole2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #21 from rguenther at suse dot de ---
nOn Sat, 27 Sep 2014, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
>
> Jan Hubicka changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655
Julian Taylor changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
Bug ID: 63406
Summary: -Warray-bounds false positive with -O3
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #2 from Jakub Jelinek ---
(In reply to Igor Zamyatin from comment #1)
> Would like to ask here first - will something like following be ok:
> +typedef struct
> +{
> + tree parm;
> + tree arg;
> +} decl_pair;
> +
> +static vec vec_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
Jonathan Wakely changed:
What|Removed |Added
Target||mingw-w64
--- Comment #1 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #1 from Igor Zamyatin ---
Would like to ask here first - will something like following be ok:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index bf549ad..f453bc5 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Sep 29 09:06:31 2014
New Revision: 215680
URL: https://gcc.gnu.org/viewcvs?rev=215680&root=gcc&view=rev
Log:
2014-09-29 Paolo Carlini
PR c++/51385
* g++.dg/temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Bug ID: 63405
Summary: Internal compiler error when building OpenAxiom on
linux/amd64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
--- Comment #4 from Paolo Carlini ---
This is fixed in 4.9.0, I'm adding the testcase and closing the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056
--- Comment #2 from Jonathan Wakely ---
(In reply to Piotr Dziwinski from comment #1)
> I would also second the proposal to fix this issue by implementing flat
> version of std::tuple. Perhaps the existing std::tr1::tuple implementation
> can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
Bug 36534 depends on bug 37173, which changed state.
Bug 37173 Summary: Check whether intrinsic assignment between character kind=1
/ 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
Francois-Xavier Coudert changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173
--- Comment #5 from Francois-Xavier Coudert ---
(In reply to Tobias Burnus from comment #3)
> We still might add a -std=f2008 check there.
I find the same wording in my local copy of F2003, actually:
"If variable and expr have different kind ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Markus Trippelsdorf changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
--- Comment #3 from rguenther at suse dot de ---
On Fri, 26 Sep 2014, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
>
> Jan Hubicka changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #20 from rguenther at suse dot de ---
On Fri, 26 Sep 2014, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
>
> --- Comment #14 from Jeffrey A. Law ---
> This feels like the kind of situation where
91 matches
Mail list logo
