Call the following snippet `bug.cc':
struct a {
static const int size = 0;
};
template typename T
struct p {
int a[T::size]; // Here it says error: creating array with size zero (`0')
};
pa n;
template typename T
struct q {
int a[0]; // Here it says nothing!
};
qa m;
$ g++ -v
Reading
Kazu Hirata wrote:
Hi,
I would like to announce that fold_buildN are now ready.
Great!
When and how do we want to do these conversion?
Currently, I am thinking about doing converting all of
fold (buildN (...)) and fold (build (...)) to fold_buildN as soon
as stage 2 starts, which is about one
Hi Roberto,
Should I report this as a bug?
If so, which kind of bug is it?
Isn't this c++/19989?
Paolo.
Paolo Carlini wrote:
Hi Roberto,
Should I report this as a bug?
If so, which kind of bug is it?
Isn't this c++/19989?
I should add that, on top of pt.c:tsubst (where the first error is issued
unconditionally, irrespective of -pedantic) there is the following comment:
Alexandre Oliva [EMAIL PROTECTED] writes:
On Mar 23, 2005, Ian Lance Taylor ian@airs.com wrote:
Of course, correctly modeling the effect on the condition codes
really means putting the information in the RTL so that it is
exposed to the RTL optimizers.
True, but we want to avoid that
Ian Lance Taylor ian@airs.com writes:
Looking at your suggestion makes me realize that my suggestion is too
complicated. It's not necessary to generate the combinatorial
explosion at all. We can always keep cc0 setters and cc0 users in
separate instructions. The key is to keep them from
On Thu, Mar 24, 2005 at 11:44:52AM -0500, Ian Lance Taylor wrote:
OK, here is a different approach toward eliminating cc0, based on a
combination of my earlier proposal and what Alex described. I'm
looking for comments from anybody.
One potential problem: once the NOTICE_UPDATE_CC pass is
Richard Henderson [EMAIL PROTECTED] writes:
Note that there's no longer any insn that *sets* cc_reg. I think
that's a bit dangerous.
Hmmm, good point.
One solution to this is to convert the new setter to
[(set (reg 1) (plus (reg 1) (reg 2)))
(set (reg cc_reg) (unspec
Hi,
only one question please, gcc can compile cobol source? (procobol)
thanks very much!
bye
Ian Lance Taylor ian@airs.com writes:
3) Write a new CC0 collapse pass. This pass is run immediately
after RTL expansion. It walks the instruction stream looking for
instructions which set and use CC_REG. At this point these
instructions will always be adjacent. The pass combines them
Zack Weinberg [EMAIL PROTECTED] writes:
Ian Lance Taylor ian@airs.com writes:
3) Write a new CC0 collapse pass. This pass is run immediately
after RTL expansion. It walks the instruction stream looking for
instructions which set and use CC_REG. At this point these
instructions will
[If you're in the explicit CC: list for this mail, I've mentioned you
explicitly below, and I'm hoping that you'll be able to provide me
some feedback.]
I've looked through the 36 critical (i.e., wrong-code, ice-on-valid, or
rejects-valid) regressions open against 4.0. They are categorized
On Mar 24, 2005, at 10:32 AM, Galli Andrea wrote:
only one question please, gcc can compile cobol source? (procobol)
You know, there is this thing called google. It is wonderful, you
can type http://www.google.com into your favorite web browser, and
the type GNU cobol and then return, and it
Truly Critical
--
19225 Segmentation fault with VLAs, affects GLIBC
This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAME
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when it gets back to the landing pad?
There is no direct
Stefan Strasser wrote:
movl %ebx, -200(%ebp)
movl %ebx, -196(%ebp)
movl %eax, 4(%esp)
movl -200(%ebp), %edx
movl -196(%ebp), %ecx
It is hard to say without a testcase, but my first guess would be reload
inheritance and/or the post-reload cse pass.
Reload may need to load/store something
Ian Lance Taylor ian@airs.com writes:
Zack Weinberg [EMAIL PROTECTED] writes:
I'm not understanding why this is a separate pass, instead of
generating the combined instructions directly in the expander. I
think generic expander support for compare-and-branch instructions
already exists...
On Mar 24, 2005, at 12:35 PM, James E Wilson wrote:
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
Undefined behavior on execution, not on translation.
It's still a stretch on the word valid.
r~
Steve Ellcey wrote:
Any optimization experts care to take a look at this test case and help
me understand what is going on and if this change from 3.4 to 4.0 is
intentional or not?
Use the -da -fdump-tree-all options, and start looking at the dumps.
The first thing I notice is that in the RTL
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already suggested
a solution though not a patch (disable deferred argument popping when a
call can throw). It isn't marked critical though, so I
On Mar 24, 2005, at 3:08 PM, James E Wilson wrote:
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already
suggested a solution though not a patch (disable deferred argument
popping when a call
Michael LeBlanc wrote:
Does that option do anything except supply -maltivec implicitly?
As explained in the install docs, it does two things, enables -maltivec
by default, and enables -mabi=altivec by default.
This option has been deprecated and removed in the upcoming gcc-4.0
release. The
On Thursday 24 March 2005 23:28, James E Wilson wrote:
I'd suggest filing a bug report for this problem to make sure it gets
fixed.
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general, yes, but we will probably always need some RTL loop
On Mar 24, 2005, at 7:31 PM, James E Wilson wrote:
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general, yes, but we
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote:
Jim you know that -fmove-loop-invariants enables the new RTL BB based
loop optimizer? This option was added back in 3.4.0.
No, I don't, and I stupidly didn't bother to check. I thought he was
talking about some tree-ssa option.
I tried it, it
On Mar 24, 2005, at 8:09 PM, James E Wilson wrote:
I tried it, it doesn't help. It solves neither the loop invariant code
motion problem nor the do-loop optimization problem.
The do-loop optimization which 3.3/3.4 was doing was invalid (see the
bug
referenced below).
I filed it under PR 19210
Targets, such as Windows, that don't have getopt() will probably have
get the following error when compiling binutils.
gcc -DHAVE_CONFIG_H -I.
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I. -D_GNU_SOURCE
-I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I../bfd
Daniel Berlin wrote:
Truly Critical
--
19225 Segmentation fault with VLAs, affects GLIBC
This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
Hi
There are occasions, especially when bootstrapping a whole new World where
one needs to build GCC multiple times, that you don't want to be
bootstrapping GCC on every invocation, only the first.
On x86 with GCC-4 and above, `make bootstrap' results in the compiler being
built with
20263 SPARC64 ASM bug
Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should Add CC you when you
comment on specific PRs in order to speed up the
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From fredrik dot huss at home dot se 2005-03-24
09:21 ---
Thanks for looking into this!
Yes, I was meaning when -ffast-math is NOT used, so maybe this is completely
unrelated. But I was thinking that even without -ffast-math, this should not
require a full
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-24
09:25 ---
Subject: [PR middle-end/20491] combine generates bad subregs
Combine doesn't ensure the subregs it generates are valid. In most
cases, insn recog will reject the invalid subregs, or reload will
somehow
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:28
---
It would be nice if the multiplication worked like this also for
complexdouble, even without -ffast-math. Or, is there something in the
standard which would disallow this?
I don't think there is. But, AFAIK,
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:33
---
Side note: here we are talking about the specializations for real/double/long
double, therefore no _M_real but __real__ _M_value and so on. In this case we
rely on the compiler to expand the operations using to
GNAT.Sockets.Inet_Addr (255.255.255.255) raises an socket error because
inet_addr returns -1 which is the same as error indication.
I think there are two ways of resolving this problem:
1) Make a special case for 255.255.255.255 inside GNAT.Sockets.Inet_Addr and
return
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:55
---
Argh! No, I was totally wrong: I tried fixing this problem some time ago and
did something wrong. We can fix it in the library. Sorry.
--
What|Removed |Added
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-24
10:46 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 24, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
Combine doesn't ensure the subregs it generates are valid. In most
cases, insn
--- Additional Comments From pluto at pld-linux dot org 2005-03-24 11:07
---
(In reply to comment #15)
thats the same issue like the konqueror crash which I couldn't
find a workaround for in gcc either.
Please looka at the PR19265 testcase
--- Additional Comments From pcarlini at suse dot de 2005-03-24 11:08
---
Richard, can you possibly have a look? Why fold_complex_mult_parts doesn't
optimize well complex * real also when no-fast-math?
--
What|Removed |Added
The SH lib1funcs.asm contains numerous small functions that save code size
for a static link, but still are smaller than the PLT size for all
link-compatible subtargets (1). Such functions
should never be exported from a shared libgcc.
(1) If, say, there is a function that is large for the SH3,
The SH lib1funcs.asm contains numerous small functions that save code size
for a static link, but still are smaller than the PLT size for all
link-compatible subtargets (1). Such functions
should never be exported from a shared libgcc.
(1) If, say, there is a function that is large for the SH3,
--- Additional Comments From pcarlini at suse dot de 2005-03-24 11:39
---
The middle-end problem seems that, when no-fast-math, c99-conforming method, we
are not implementing systematically the special cases in G.5.1/2 (and /3 for the
division).
--
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-24
11:43 ---
I propose to back out the sh specific part of the following patch on
the gcc 4.0 branch. This should be done before the 4.0 release, in
order to avoid people being stuck with shared objects that
reference
--
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Last
--
What|Removed |Added
CC||mueller at kde dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-24
12:12 ---
*** Bug 20616 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20617
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-24
12:12 ---
*** This bug has been marked as a duplicate of 20617 ***
--
What|Removed |Added
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-03-24 12:33 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
Combine doesn't ensure the subregs it generates are valid. In most
cases, insn recog will reject the invalid subregs,
This occurs in a legacy package that I inherited.
A testcase looks like this:
$ cat v-fmt.f
program main
implicit none
integer i,n
real a(10)
a(1) = 1.
a(2) = -1.
n = 2
print 9000,(a(i),i=1,n)
9000 format (nF12.5, and that's all.)
end
$ ifort
--- Additional Comments From rwgk at yahoo dot com 2005-03-24 12:46 ---
Using the latest CVS:
gcc version 4.0.0 20050324 (prerelease)
My reproducer attached to this report
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603
is still failing.
--
http://gcc.gnu.org/bugzilla
$ gcc -v -save-temps -DHAVE_CONFIG_H -I. -g -Wall -O2 -c conf.c
Reading specs from /usr/lib/gcc/mips-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
$ gcc -v -save-temps -DHAVE_CONFIG_H -I. -g -Wall -O2 -c conf.c
Reading specs from /usr/lib/gcc/mips-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
$ gcc -v -save-temps -DHAVE_CONFIG_H -I. -g -Wall -O2 -c conf.c
Reading specs from /usr/lib/gcc/mips-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--- Additional Comments From ldarby at mips dot com 2005-03-24 12:48
---
Created an attachment (id=8447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8447action=view)
preprocessed source from the debian package 'cdcd'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
--- Additional Comments From ldarby at mips dot com 2005-03-24 12:50
---
*** This bug has been marked as a duplicate of 20621 ***
--
What|Removed |Added
--- Additional Comments From ldarby at mips dot com 2005-03-24 12:50
---
*** Bug 20619 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
--- Additional Comments From ldarby at mips dot com 2005-03-24 12:50
---
*** This bug has been marked as a duplicate of 20621 ***
--
What|Removed |Added
--- Additional Comments From ldarby at mips dot com 2005-03-24 12:50
---
*** Bug 20620 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
--- Additional Comments From schwab at suse dot de 2005-03-24 12:50 ---
3) Use inet_aton which does not have this problem. inet_addr is obsolete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20615
--- Additional Comments From pluto at pld-linux dot org 2005-03-24 13:16
---
(In reply to comment #9)
I can confirm this (unfortunately, haha).
hmm,
--save-temps option produces totally diff. plugin and behaviuor :O
this is really amazing.
# make clean all OPT=-O
rm -f dltest *.o
--- Additional Comments From bauhaus at futureapps dot de 2005-03-24 13:18
---
Subject: Re: Bug Box, combination of Ada 2005, dotted notation,
Hash_Maps, and Unbounded_String
laurent at guerby dot net wrote:
--- Additional Comments From laurent at guerby dot net 2005-03-23
--
What|Removed |Added
CC||pluto at pld-linux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--
What|Removed |Added
CC||pluto at pld-linux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
--- Additional Comments From ldarby at mips dot com 2005-03-24 13:56
---
(In reply to comment #0)
ICE appears only on the MIPS arch using 3.4.4
It doesn't appear when using 3.3.5, or on x86 using either versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
/* { dg-do run } */
/* { dg-require-alias } */
/* { dg-options -O2 } */
extern void abort (void);
int foo __asm__ (foo) __attribute__((nocommon));
extern __typeof (foo) bar __attribute__ ((weak, alias (foo)));
int
main (void)
{
if (foo != bar || foo || bar)
abort ();
return bar;
}
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-24
14:29 ---
Actually, implementing this would be a bit harder
than I thought.
It seems that the variable expression is evaluated
at runtime, so you can do things like
$ cat v-fmt2.f
program main
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|critical
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
Keywords||wrong-code
Target Milestone|---
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
--
What|Removed |Added
GCC build triplet|mips-linux |
GCC host triplet|mips-linux |
Keywords|
I built gcc from the actual snapshot (gcc-4.1-20050320) with --enable-
checking=fold and run make check.
I got ICEs fold check: original tree changed by fold on 28 different files
g++.dg/inherit/ptrmem2.C:23: internal compiler error: fold check: original tree
changed by fold
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24
15:07 ---
I cannot reproduce this with a cross compiler to mips-linux with the version of
3.4.4 20050202.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20621
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24
15:08 ---
Updated patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02251.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18851
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24
15:11 ---
Most if not all of the problems are listed in PR 16045. Well all of the
builtins related failures are listed
there.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||20623
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16045
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24
15:12 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-24 15:33
---
Created an attachment (id=8449)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8449action=view)
pr20622 patch
Here is patch I'm playing ATM with. It fixes the bug for me and passes
gcc.dg testsuite on
--- Additional Comments From pcarlini at suse dot de 2005-03-24 15:52
---
I'm recategorizing back to middle-end: really this should be properly fixed
in the middle-end.
--
What|Removed |Added
--- Additional Comments From zack at codesourcery dot com 2005-03-24 16:06
---
Subject: Re: shared SH libgcc is exporting too many
symbols
Why not just add the problematic symbols to sh/libgcc-excl.ver? That
is what it is there for.
zw
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-24
16:24 ---
Subject: Bug 20617
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-24 16:24:45
Modified files:
gcc:
If you compile this code
#include fstream
void test()
{
std::ifstream in;
}
against the actual CVS version of STLport 5.0
(http://www.breaken.de/temp/STLport.zip) you get this warning:
In member function 'typename stlp_std::basic_filebuf_CharT,
_Traits::pos_type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24
16:30 ---
(In reply to comment #0)
If you compile this code
against the actual CVS version of STLport 5.0
Two things, Please attach the preprocessed source.
Second why are you using STLport instead of the GCC's
--- Additional Comments From joern dot rennecke at st dot com 2005-03-24
16:30 ---
Subject: Re: shared SH libgcc is exporting too many symbols
pinskia at gcc dot gnu dot org wrote:
What|Removed |Added
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-24 16:49
---
Joern, why are you committing patches to 4.0 without testing? The release isn't
_that_ imminent. Also, did you see Zack's suggestion? And Mark did ask that
no one add 4.0.0 milestones without talking to him
gcc version 4.0.0 20050320 (Red Hat 4.0.0-0.35)
The code produced by this version of gcc generates unaligned access exception.
gcc 3.4.3 and 3.4.2 produces correct code
--
Summary: gcc with -O2 produces code that generates unaligned
access exception
--- Additional Comments From oliverst at online dot de 2005-03-24 16:54
---
Second why are you using STLport instead of the GCC's libstdc++?
Because we had problems with the default GCC STL in the past, so we switched to
STLport. We are also working cross-platform (GCC for linux and
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:55 ---
Created an attachment (id=8450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8450action=view)
test case
This is small test case that shows the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:57 ---
Created an attachment (id=8452)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8452action=view)
Produced assembler file
This is generated assembler source with marked instruction (---) that
generated unaligned
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
16:57 ---
According to Sven, the recent Calendar/SimpleDateFormat fix
fixed this as well.
--
What|Removed |Added
--
Bug 16990 depends on bug 8321, which changed state.
Bug 8321 Summary: SimpleTimeZone doesn't work properly for daylight saving time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8321
What|Old Value |New Value
--- Additional Comments From tsv at solvo dot ru 2005-03-24 16:58 ---
If source code compiled without optimization - no unaligned access generated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
17:00 ---
*** Bug 19682 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
17:00 ---
Duplicate PR.
*** This bug has been marked as a duplicate of 17003 ***
--
What|Removed |Added
--
Bug 16990 depends on bug 19682, which changed state.
Bug 19682 Summary: TimeZone data needs to be regenerated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19682
What|Old Value |New Value
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-24
17:01 ---
This is a wrong-code regression, and, as such, it's a critical bug for 4.0,
except that SH is not a primary or secondary platform. As such, SH bugs should
never have a target milestone; they should just
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-24
17:05 ---
Dan points out that Joern was probably referring to Andrew's downgrade, rather
than Zack's comment, when speaking about seriousness.
I'm not sure what prompted Andrew to make that change, but I certainly
1 - 100 of 191 matches
Mail list logo
