--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 09:11 ---
Here is a reduced testcase which shows the same issue:
#define vector __attribute__((__vector_size__(16) ))
vector int f()
{
int t = 4;
return (vector int){t,t,t,t};
}
vector int f1()
{
return (vector
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-25 09:26 ---
Here is a patch which fixes the problem:
Index: ../../gcc/config/rs6000/rs6000.c
===
--- ../../gcc/config/rs6000/rs6000.c(revision 123180)
+++
An attempt to divide by zero is made (causing ICE on the attached test
case) for evolution functions with zero step.
For the following evolution functions of pS[i_15].x and pS[i_15].y from the
attached test
(chrec_a = {{0, +, 1}_1, +, 0}_2)
(chrec_b = {{1, +, 1}_1, +, 0}_2)
the difference
--- Comment #1 from irar at il dot ibm dot com 2007-03-25 10:02 ---
Created an attachment (id=13281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13281action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 10:29 ---
Subject: Bug 31196
Author: tkoenig
Date: Sun Mar 25 09:29:10 2007
New Revision: 123195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123195
Log:
2007-03-25 Thomas Koenig [EMAIL PROTECTED]
PR
: in extract_insn, at recog.c:2119
The last revision known to compile OK on that particular setup was: 123178. I
can reproduce it with the attached preprocessed source and the following
command line:
$ /home/fxcoudert/gfortran_nightbuild/ibin-20070325/./gcc/cc1 -fpreprocessed
foo.i -mtune=i386
gnu_dev_major
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:01
---
Subject: Bug 30877
Author: fxcoudert
Date: Sun Mar 25 10:01:23 2007
New Revision: 123196
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123196
Log:
PR fortran/30877
* fortran/interface.c
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:02
---
Fixed, thanks Joost for the report!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-03-25
11:12 ---
http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:19
---
(In reply to comment #1)
http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html
Yes, thanks, I know. I followed in my patch
(http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01605.html) the idea I already
had at that
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:49
---
$ cat nan.f90
real :: nan, x
x = 7.2
nan = 0.0
nan = nan / nan
print *, minval((/ nan, x /)), maxval((/ nan, x /))
print *, minval((/ nan /)), maxval((/ nan /))
print *, minloc((/
Hi Ian,
Your fix for PR31034 worked for 18 out of 20 affected applications in Debian,
but there are 2 applications that still exhibit a related ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 qdbm-depot.c
qdbm-depot.c: In function 'dpsnaffle':
qdbm-depot.c:2: internal compiler
--- Comment #1 from tbm at cyrius dot com 2007-03-25 12:28 ---
Created an attachment (id=13282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13282action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
--- Comment #9 from dorit at gcc dot gnu dot org 2007-03-25 13:08 ---
Subject: Bug 30784
Author: dorit
Date: Sun Mar 25 12:08:29 2007
New Revision: 123197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123197
Log:
PR tree-optimization/30784
* fold-const.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-25 13:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
size and ubound are lost when passing an array as argument of a procedure
--
Summary: wrong values for ubound and size of deferred shape
arrays
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-25 14:38
---
Created an attachment (id=13283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13283action=view)
program showing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-25 14:41
---
$ FC=gfortran; $FC -v; $FC -o test test.f; echo; ./test
Lecture des spécification à partir de
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs
Target: x86_64-pc-linux-gnu
Configuré avec: /usr/src/gcc-4.1.2/configure
--- Comment #5 from dayas2003 at yahoo dot com 2007-03-25 15:07 ---
I am unsing the following version:
arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar
I get the same error as said above. I am not sure whether to modify the Code [
there are many files; so painful solution :-(
--- Comment #12 from s_j_newbury at yahoo dot co dot uk 2007-03-25 16:52
---
(In reply to comment #11)
I have everything built except for libjava/exception.cc which fails as seen
below.
libjava/exception.cc needs special handling of the EABI unwind support as is
done in the
--- Comment #2 from pthaugen at us dot ibm dot com 2007-03-25 18:38 ---
I hit the same ICE building the 191.fma3d benchmark from cpu2000 when compiling
lsold.f90 with -O2 -ftree-loop-linear.
--
pthaugen at us dot ibm dot com changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-25 18:41 ---
I think this is a regression also on the 4.2 branch now since the set of
patches that caused this is also there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 18:58 ---
Note, I think decLibrary.c changed but does not cause this not to be an user
visible regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
This happes trying to compile gettetxt-0.16 with -O3 -mthreads -msse2 -mmmx ...
Note that it compiles just fine without all the
'-march=pentium4 -msse -msse2 -mmmx -O3 -mfpmath=sse -mthreads -Wall -v
-save-temps' options ...
Here is the output
/bin/sh ../libtool --tag=CC --mode=compile
Version exacta: gcc version 4.1.0
System type: Windows Vista
Manufacturer: Dell
Model: Inspiron I6400
Rating: Windows Experience Index: Unrated
Processor: Genuine Intel(R) CPU T2060 @ 1.60GHz 1.60 GHz
Memory(Ram):
--- Comment #1 from terminatorul at gmail dot com 2007-03-25 19:17 ---
Created an attachment (id=13284)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13284action=view)
C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31347
--- Comment #2 from hjl at lucon dot org 2007-03-25 19:18 ---
Where is the attached preprocessed source?
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 ---
*** This bug has been marked as a duplicate of 29826 ***
*** This bug has been marked as a duplicate of 29826 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 ---
*** Bug 31347 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:22 ---
Vista is not support right now IIRC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:23
---
Created an attachment (id=13285)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13285action=view)
Preprocessed source file triggering the ICE
Here's the preprocessed source, sorry for forgetting it in the
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
*** This bug has been marked as a duplicate of 30972 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
*** Bug 31348 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:38
---
Reduced testcase:
$ cat a.c
typedef struct
{
unsigned char bits;
} decNumber;
typedef struct
{
unsigned char bytes[1];
} decimal32;
decNumber *__decimal32ToNumber (const decimal32 *, decNumber *);
void
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-25 19:40
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-25 20:34 ---
Thomas, the testcase fails the execution test on i386-darwin at all
optimization levels in an up-to-date tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
--- Comment #13 from tobi at gcc dot gnu dot org 2007-03-25 20:51 ---
I have a patch which does eveything, except detecting branches to END DOs. I
can't seem to figure out how to do this in a sensible way without introducing a
replacement quadratic bottleneck :-(
--
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-03-25 20:55 ---
(In reply to comment #5)
Thomas, the testcase fails the execution test on i386-darwin at all
optimization levels in an up-to-date tree.
*sigh*
Can you maybe investigate the following:
- print line1 and line 2
--- Comment #2 from pcarlini at suse dot de 2007-03-25 21:01 ---
I'm looking into this: apparently the problem is just (or mostly) that at the
beginning of instantiate_decl we are not copying DECL_IN_SYSTEM_HEADER (d) into
in_system_header: doing it fixes the test here (and avoids the
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-25 21:56 ---
I do not believe the patch will help with the original missed optimization
because the backend never sees a direct assignment from the CONSTRUCTOR -- it
already is placed in memory. The example in comment #2 is
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-03-25 22:04
---
I'll give this a shot.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 22:18 ---
Subject: Bug 31297
Author: tkoenig
Date: Sun Mar 25 21:17:51 2007
New Revision: 123200
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123200
Log:
2007-03-25 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-25 22:55 ---
(In reply to comment #4)
I do not believe the patch will help with the original missed optimization
because the backend never sees a direct assignment from the CONSTRUCTOR -- it
already is placed in memory. The
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-25 23:05 ---
Now the patch does not solve the following testcase:
int main1 (int X)
{
int s = X;
int i;
for (i = 0; i 96*16; i+=16)
s += i;
return s;
}
For this one to be fixed, we need to define an insn which
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-25 23:36 ---
Something like:
(define_insn_and_split altivec_dupmode
[(set (match_operand:V 0 register_operand v)
(vec_duplicate: (match_operand: 0 r)))
(clobber (match_operand:V 3 memory_operand =Z))]
To quote from the output of gcc -v --help on
gcc (GCC) 4.3.0 20070323 (experimental):
--
The following options are specific to the language Ada:
-gnatoptions Specify options to GNAT
The following options are specific to the language C:
No options
gcc -v --help is inconsistent about where it places its output. If I try to
redirect the output to a file (which is rather a reasonable thing to do, given
how long it is!), some of it still gets printed to the console via standard
error:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 23:48 ---
This was caused by:
2007-02-12 Nick Clifton [EMAIL PROTECTED]
* doc/invoke.texi (Overall Options): Document --help=.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What
When an option is shared between multiple front ends, the output of gcc -v
--help uses the documentation string from the first front end for which it is
listed.
Ada is listed before C, and thus all of the shared Ada/C options use the Ada
documentation, rather than the C documentation.
When an option is present in multiple front ends, the gcc -v --help output
assumes that the documentation is the same in all of the front ends for which
the option is present, and only reports the documentation string for the first
front end for which it appears.
For example, in 4.2, the Ada
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:07 ---
*** This bug has been marked as a duplicate of 31306 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 00:07 ---
*** Bug 31294 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:13 ---
It probably shouldn't say rhs in the error message, either.
It looks like we don't look through the references correctly when determining
the length of the rhs, though I can't see exactly where this goes wrong.
--
Consider the following output:
~/bin-trunk/bin/gcc --help=target
The following options are target specific:
-m128bit-long-doublesizeof(long double) is 16
-m32Generate 32bit i386 code
[...]
-muclibc
I'm guessing at middle-end here, maybe it is target...
I don't think it is correct for NaNs to fail any comparison.
They should only fail comparisons which include equality.
$ cat compare.c
#include stdio.h
int main()
{
float nan, x;
nan = 0.0;
nan = nan / nan;
x = 3.2;
The documentation in invoke.texi for the --help= option only lists the
optimizers, warnings, target, and params values that the option can
take. However, it can also take a language name as a value, and this isn't
documented.
--
Summary: --help=language option isn't documented.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:27 ---
NaN's are unordered so they will compare false for ordered operators.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31354
Consider the following output:
~/bin-trunk/bin/gcc --help=fortran
The following options are supported by, amoung others, the language :
-I This switch lacks documentation
[...]
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
As documented, using multiple --help=value options in one command line
produces an output that concatenates the output from the various --help=value
options.
However, using both --help and --help=value gives only the --help output,
regardless of the order in which they are specified.
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-26 01:00
---
Turns out this is not a duplicate of 31199. However its is closel related. I
wll work this one as well.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #5 from hjl at lucon dot org 2007-03-26 01:18 ---
It also happens with -Os:
bash-3.1$ /export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/ -m32 -S -o bar.s bar.i
-Os
bar.i: In function isinfd32:
bar.i:22:
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-26 01:44
---
Richard, are you able to confirm this bug?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl at lucon dot org 2007-03-26 01:55 ---
Jan, it may be related to your code:
http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00263.html
Any idea?
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-26 01:59 ---
This works on the trunk at least on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
For:
int *f(int *a, int b, int c)
{
int i;
a --;
*a = 1;
for (i = 0;ib;i+=c)
(a[i]) = 0;
return a;
}
CUT
I get in the final_cleanup:
MEM[index: ivtmp.35, offset: 4294967292] = 0;
And I noticed that ivtmp.29 is of type long unsigned int which seems
--- Comment #5 from bangerth at dealii dot org 2007-03-26 03:13 ---
Manuel,
thanks for (re-)submitting the patch today. I don't have the infrastructure
to test patches any more these days, but I appreciate that someone takes
up the issue again.
I think the text duplication is not the
--- Comment #7 from hjl at lucon dot org 2007-03-26 03:15 ---
It looks like expr.c and i386.c don't agree how to generate push
instuction. i386.c has gen_push and expr.c has emit_single_push_insn.
If emit_single_push_insn is called, it will generate invalid patten:
(insn 10 9 11 3 (set
--- Comment #8 from hjl at lucon dot org 2007-03-26 04:04 ---
The invalid insn is added via
#0 add_insn (insn=0x2aafc690)
at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:3411
#1 0x004fb88d in emit_insn (x=0x2aafc690)
at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:4336
#2
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:23
---
Subject: Bug 31199
Author: jvdelisle
Date: Mon Mar 26 04:23:15 2007
New Revision: 123205
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123205
Log:
2007-03-25 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from patchapp at dberlin dot org 2007-03-26 04:40 ---
Subject: Bug number PR 22156
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01625.html
--
--- Comment #6 from patchapp at dberlin dot org 2007-03-26 04:41 ---
Subject: Bug number PR 14737
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01649.html
--
--- Comment #14 from patchapp at dberlin dot org 2007-03-26 04:41 ---
Subject: Bug number PR 18937
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01650.html
--
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:41
---
Subject: Bug 31199
Author: jvdelisle
Date: Mon Mar 26 04:41:29 2007
New Revision: 123207
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123207
Log:
2007-03-25 Jerry DeLisle [EMAIL PROTECTED]
PR
The eventual consensus of the ml thread gcc 4.2 more strict check for
function called through a non-compatibletype [1]:
Mark Mitchell wrote:
Ian Lance Taylor wrote:
I realized that I am still not stating my position very clearly. I
don't think we should make any extra effort to
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-26 05:43
---
I agree with Joseph that STRIP_SIGN_NOPS should not be removing changes in
precision that may change the value and that, indeed, mode is probably being
used as an inaccurate proxy for precision.
--
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-03-26 05:58
---
Created an attachment (id=13286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13286action=view)
the working case
The problem arise when the subroutine is not defined in a contains statement in
the main
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:01 ---
Can you show the exact code from openssl which has the problem, there might be
better ways of writting the code instead of what they are doing right now.
This code is still undefined and I don't think we really
Testcase:
void f(int *a)
{
int i;
for (i = 0;i100;i++)
a[i] = 0;
}
---cut-
we get:
_f:
li r0,0
li r2,4
stw r0,0(r3)
li r0,99
mtctr r0
L2:
li r0,0
stwx r0,r2,r3
addi r2,r2,4
bdnz L2
blr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:48 ---
I get:
Set in insn 47 is invariant (0), cost 4, depends on
Where insn 47 is the load constant:
(insn 47 46 48 3 (set (reg:SI 156)
(const_int 0 [0x0])) 328 {*movsi_internal1} (nil)
(nil))
If I change
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2007-03-26 07:00
---
Here is a new patch. I need someone to test on SPEC. It is very simple.
Index: transfer.c
===
*** transfer.c (revision 123205)
--- transfer.c
--- Comment #4 from daney at gcc dot gnu dot org 2007-03-26 07:07 ---
Subject: Bug 31228
Author: daney
Date: Mon Mar 26 07:07:13 2007
New Revision: 123208
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123208
Log:
PR libgcj/31228
* configure.ac: Add checks for
--- Comment #5 from daney at gcc dot gnu dot org 2007-03-26 07:13 ---
Committed to the 4.2 branch as well.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-26 07:19 ---
(In reply to comment #3)
I haven't seen anything in the Fortran 2003 standard forcing the subroutines
to
be in the contains statement.
In this case the interface is said to be implicit and the standard does not
92 matches
Mail list logo
