--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
06:51 ---
Subject: Bug 23357
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 06:50:57
Modified files:
gcc/cp : ChangeLog cp-tree.def
Added files:
--- Additional Comments From skyhover at hotmail dot com 2005-09-16 05:53
---
There are some similar code in function "gfc_copy_array_ref" at line 53-55.
There, "src" are kind of recursively copied into "dest".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23905
--- Additional Comments From skyhover at hotmail dot com 2005-09-16 05:45
---
Thanks for your information and clarification. I agree now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23907
--- Additional Comments From jeff at panasas dot com 2005-09-16 05:44
---
Created an attachment (id=9738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9738&action=view)
Xor test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
We use some optimized XOR routines for software RAID. Unfortunately, the
compiler generated incorrect code when this was compiled for Redhat 7.3 +
2.4.24 (this is normally kernel code). I later found out that all versions of
gcc that I tested (up to FC4 - 4.0.0 20050519 (Red Hat 4.0.0-8)) had
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
04:26 ---
Actually my testcase works with the next runtime also but that might be because
it is picking the first
Foo and the one in 2.so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
04:24 ---
I am going to implement the next runtime behavior. The following code works
and is just like the code
in your testcase too but works with both runtimes:) :
#include
#include
#include
#ifdef __NEXT_RUN
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:55 ---
The next runtime does:
objc: Both ./1.so and ./2.so have implementations of class Foo.
objc: Using implementation from ./2.so.
What do you think we should do, use the later one of the first or abort?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:54 ---
Here is the "real" backtrace:
#0 0x00064374 in sarray_lazy_copy (oarr=0x0) at
/Users/pinskia/src/libobjc/gcc/libobjc/sarray.c:484
#1 0x000668d0 in __objc_install_dispatch_table_for_class (class=0x31034) a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:50 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:50 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From michel at colorado dot edu 2005-09-16 03:49
---
Subject: Re: Template subclasses do not find variables in
their parent classes
I read this. What I am questioning is the logic behind this. Isn't the
logic of template that if you were to replace the typenam
--
What|Removed |Added
Target Milestone|--- |3.0.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=857
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:48 ---
Close as invalid.
--
What|Removed |Added
Status|REOPENED|RES
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:48 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--
What|Removed |Added
Target Milestone|--- |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=765
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:45 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:44 ---
reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=603
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:43 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:42 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:42 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:41 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:40 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:40 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=457
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=270
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:36 ---
(In reply to comment #2)
> No idea why that is. What's the logic behind this? Make my code twice as
> long?
The standard says this, did you read the page I gave? If not then I copied and
pasted what is r
--- Additional Comments From michel at colorado dot edu 2005-09-16 03:32
---
Subject: Re: Template subclasses do not find variables in
their parent classes
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
> 02:47
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:27 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:26 ---
This looks like a bug. However I don't agree with this analysis.
We should be applying the same transformation to both l and r.
Also, multiplying then dividing by the same value makes no sense.
--- Additi
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:26 ---
This looks like a bug. However I don't agree with this analysis.
We should be applying the same transformation to both l and r.
Also, multiplying then dividing by the same value makes no sense.
--
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:24 ---
No more NIST failures
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:20 ---
Fixed by patches to PR21875
--
What|Removed |Added
Status|NEW
--
Bug 23379 depends on bug 23364, which changed state.
Bug 23364 Summary: missing format reversion for internal write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23364
What|Old Value |New Value
--
--
Bug 19276 depends on bug 23379, which changed state.
Bug 23379 Summary: compiler segfault with internal write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
What|Old Value |New Value
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:14 ---
Resolved by patches to PR21875
--
What|Removed |Added
Status|NEW
--- Additional Comments From bauhaus at futureapps dot de 2005-09-16 03:11
---
looking at tests/res/string.h in the build area, it does lack \n at EOF,
so the message is correct. (All other files do have \n at EOF.)
inclhack.def:2004 has the following comment.
/* The string.h result is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
02:47 ---
Read http://gcc.gnu.org/gcc-3.4/changes.html
This is not a bug.
--
What|Removed |Added
Template subclasses do not find variables in their parent classes
Example code that should compile and does not:
template
class A {
protected:
S maxIt;
public:
A(S x) {maxIt = x;}
};
template
class B : public A {
public:
B(S d) : A(d) {
maxIt *= 2;
}
};
B f()
{
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:34
---
I'm not sure what this function is really accomplishing. The
line "*dest = *src;" isn't copying src to dest. We simply
have set *dest to point to src. So, the for loop is a NOP.
Of course, I could be missi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
02:16 ---
Unassigning for now.
--
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:01
---
gfc_simplify_radix is used in intrinsic.c for simplification of the
RADIX intrinsic function. The standard defines RADIX for REAL and
INTEGER. See 13.14.84.
program mn
complex z
print*, radix(z)
end p
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
01:54 ---
Subject: Bug 23896
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-16 01:53:43
Modified files:
gcc/cp : Change
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-16
01:54 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED|RESO
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
01:51 ---
Subject: Bug 23896
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 01:50:26
Modified files:
gcc/cp : ChangeLog pt.c
gcc/testsuite
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
01:03 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|NEW |RESOL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:58 ---
Fixed in 4.1.0 by:
2005-09-12 Ian Lance Taylor
PR g++/7874
* cp-tree.h (struct lang_decl_flags): Add hidden_friend_p
bitfield. Make dummy bitfield one bit smaller.
(DECL_
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 00:45
---
Test vect-97.c currently passes on ia64-linux and passed on alpha-dec-osf5.1b
on 20050805, and the submitter said it passes on ia64-hpux; this PR can
probably be closed.
--
http://gcc.gnu.org/bugzilla/show
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:53 ---
Fixed so closing.
--
What|Removed |Added
Status|UNCONFIRMED |RES
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:52 ---
I think this is a dup of bug 7088 but I cannot prove it for sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
We noticed the function has no switch case for "BT_COMPLEX" by similarity check
against other functions such as "gfc_simplify_range" in the same file. I think
it's reasonable for a complex to have a radix. So one "case BT_COMPLEX:" may be
needed just after "case BT_REAL:" at line 2513. Could y
--- Additional Comments From geoffk at geoffk dot org 2005-09-16 00:01
---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
On 15/09/2005, at 3:53 PM, joseph at codesourcery dot com wrote:
> Yes, "spelling" is meant in terms of the source code characters.
> The idea is t
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
23:37 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, neil at daikokuya dot co dot uk wrote:
> > Yes, "spelling" is meant in terms of the source code characters.
> > The idea
--- Additional Comments From ppluzhnikov at charter dot net 2005-09-15
23:31 ---
The line '#0 ' causes trouble for other tools that work with
the output from 'gcc -E'; e.g. edgcpfe refuses to parse it:
$ gcc -E - < /dev/null > junk.i && edgcpfe --c junk.i
"", line 1: error: invalid lin
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:58 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
joseph at codesourcery dot com wrote:-
> I don't believe I said I'd file a DR unless I saw a defect. There is no
> defect because models A or C
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
22:53 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, geoffk at gcc dot gnu dot org wrote:
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 -
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:53 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
geoffk at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 ---
> (In repl
geoffk at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 ---
> (In reply to comment #39)
> > Another reason why spelling needs preserving (in addition to implementing #
> > correctly) is for the constraints on duplicate macr
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:50 ---
Subject: Re: switch and struct
pinskia at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
> 14:22 ---
> Small testcase:
> void f(int i)
>
pinskia at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
> 14:22 ---
> Small testcase:
> void f(int i)
> {
> switch (i)
> {
> case 1:
> struct a *b;
> }
> }
>
> But IIRC this is invalid code as variable defintion
Line 422 in the file is a if-statement:
if (l_stride != NULL)
mpz_cdiv_q (X2, X2, r_stride->value.integer);
I am not clear about the functionality of "mpz_cdiv_q", but I think the
condition should be "r_stride != NULL" by looking at its surroundings and
complying to certain consistenc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
22:36 ---
Fixed by:
2005-09-14 Christopher Faylor <[EMAIL PROTECTED]>
* pex-win32.c: Include "windows.h".
(backslashify): New function.
(fix_argv): Use backslashify to convert path to window
The function is supposed to copy expressions from "src" to "dest", however, at
line 486 and 487:
dest->lower[i] = gfc_copy_expr (dest->lower[i]);
dest->upper[i] = gfc_copy_expr (dest->upper[i]);
"dest" are misused as the arguments in the parentheses. Both of them should be
"src", I th
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
22:34 ---
(In reply to comment #39)
> Another reason why spelling needs preserving (in addition to implementing #
> correctly) is for the constraints on duplicate macro definitions.
>
> #define foo \u00c1
> #define fo
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
22:20 ---
I think the relevant part of the C++ standard here is [temp.inst] paragraph 5:
If the overload resolution process can determine the correct function to call
without instantiating a class
template definitio
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-15 22:14
---
This changed with the following patch from geoffk:
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00723.html
--
What|Removed |Added
---
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-15
22:05 ---
Now we have again (?? appeared not too long ago) DOM taking all time and memory
threading 1 times repeating
if (__priority == 65535)
{
if (__initialize_p == 0)
{
__comp_dto
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-15
22:05 ---
Fix checked in
--
What|Removed |Added
Status|NEW |RESOLV
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-15
22:02 ---
Subject: Bug 16032
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-15 22:02:14
Modified files:
libjava: ChangeLog interpret.cc verify.cc defi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
21:53 ---
As I mentioned in comment 1, this is not a bug as namelookup comes before
access checking. This is
what the standard says.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
21:51 ---
Namelookup happens before access checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23904
class OtherClass;
class MyClass
{
public:
const OtherClass* GetOther() const { return ( m_other_p ); }
protected:
OtherClass* GetOther() { return ( m_other_p ); }
OtherClass *m_other_p;
friend class FriendClass;
};
In this case friend classes are allowed to acce
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
We are now emitting duplicate dump file numbers:
file.c.t10.cleanup_cfg
file.c.t10.lower
This started happening after Paolo's pass reorg. He agreed to look at this.
--
Summary: Duplicate dump file numbers
Product: gcc
Version: 4.1.0
Status: UNCONFIR
--- Additional Comments From dank at kegel dot com 2005-09-15 21:39 ---
Sounds like we're in violent agreement, then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16782
--- Additional Comments From olly at survex dot com 2005-09-15 21:38
---
Confirmed fixed in:
g++-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7)
--
What|Removed |Added
-
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-15
21:31 ---
Why is this marked as DR 278? I think it's DR 488.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21514
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-15
21:19 ---
Nathan, do you have any insights about this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23513
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
For 20001226-1.c at -O3, i get:
Execution times (seconds)
tree VRP : 11.32 (10%) usr 0.08 ( 9%) sys 11.68 (10%) wall
3194 kB ( 8%) ggc
tree operand scan : 28.39 (26%) usr 0.17 (18%) sys 29.00 (25%) wall
2722 kB ( 7%) dominance frontiers : 35.35 (32%) usr 0.13
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-15
20:52 ---
Same on my AMD64/Linux box.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From bauhaus at futureapps dot de 2005-09-15 20:33
---
Does not work for me, checkouts from Sep. 8, and
from today (Sep. 15). Exact same error when running
make check, after make bootstrap.
Debian stable, SMP, autogen 5.6.6-2, autoconf 2.59a-3,
.../configure --
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-15
20:17 ---
Subject: Bug 23288
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-15 20:17:09
Modified files:
libjava: ChangeLog
libjava/java/net:
--- Additional Comments From fitzsim at redhat dot com 2005-09-15 20:17
---
Fixed on mainline. Closing.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
20:15 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
20:14 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
20:12 ---
Confirmed, reduced testcase:
file1.c:
int g(void);
int main(void)
{
return g();
}
file2.c:
static int f(int a, int b, int c) __attribute__((noinline));
static int f(int a, int b, int c)
{
return a+
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
19:48 ---
Really memcpy should only cause permissiveness at the tree level and nothing
else as the memcpy
should always be expanded to a load/store if alignedness does not matter.
--
http://gcc.gnu.org/bugzilla/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
19:44 ---
Confirmed, this seems like a good approach at least to me.
--
What|Removed |Added
OtherBugsDe
Dom jump-threading iteration can partially or completely unroll a loop. This
prevents analysis of number of iterations and inhibits loop optimizations by
hiding the loop.
http://gcc.gnu.org/ml/gcc/2005-09/msg00303.html
--
Summary: Dom jump-threading unrolls loops
Product:
--
What|Removed |Added
GCC target triplet|i386-redhat-linux and |
|x86_64-redhat-linux |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23885
--- Additional Comments From gdr at integrable-solutions dot net
2005-09-15 19:33 ---
Subject: Re: Accepts qualified member function declaration in class
"jason at redhat dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: Accepts qualified member function declaration
| in class
|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
19:28 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From laurent at guerby dot net 2005-09-15 19:19
---
(In reply to comment #5)
> On 4.1.0 20050914 on s390-linux, two tests have similar failures:
Ooops: 4.0.2 20050913 (prerelease) (since 4.1.0 does not bootstrap because of
PR22533
--
http://gcc.gnu.org/bugzi
--- Additional Comments From jason at gcc dot gnu dot org 2005-09-15 19:18
---
Please try GCC 4. We're unlikely to work on tweaking the performance of the GCC
3.4 line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18192
--- Additional Comments From laurent at guerby dot net 2005-09-15 19:17
---
On 4.1.0 20050914 on s390-linux, two tests have similar failures:
,.,. CXB4005 ACATS 2.5 05-09-14 20:15:52
CXB4005 Check that the functions To_COBOL and To_Ada produce
correct results.
*
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-15 19:16
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-15
19:12 ---
Subject: Bug 23139
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-15 19:12:00
Modified files:
fixincludes: Change
--- Additional Comments From laurent at guerby dot net 2005-09-15 19:12
---
Happens on s390 too.
stage1/xgcc -Bstage1/
-B/home/uweigand/fsf/gcc-head-install/s390-ibm-linux/bin/ -c -g -O2
-gnatpg -gnata -I- -I. -Iada -I../../gcc-head/gcc/ada
../../gcc-head/gcc/ada/a-elchha.adb -o ada/a-e
1 - 100 of 172 matches
Mail list logo
