Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
ority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
int*]'
x.cc:4: instantiated from here
4.3.0/parallel/random_shuffle.h:471: error: 'partial_sum' was not declared in
this scope
--
Summary: parallel v3: more functions not in right namespace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
o something like
while (p!=q)
acc += *p++;
in which case the rhs is converted to int. The current implementation
attempts to use an accumulator of type 'bool'.
W.
--
Summary: parallel v3: std::accumulate uses accumulator of wrong
type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33488
lt constructor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
ry: parallel v3: std::accumulate assumes iterators have
std::iterator_traits declared
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
t org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33491
--- Comment #3 from bangerth at dealii dot org 2007-09-19 03:13 ---
Confirmed. Using sizeof with an argument that appears to have side effects
but isn't evaluated seems like an error waiting to happen.
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:04 ---
As I've said in the other report, I believe you shouldn't rely on the
existence of iterator_traits for the iterator type. You should use the
return type of dereferencing the iterator.
W.
--
http://g
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:11 ---
(In reply to comment #1)
> That this is missing in the requirement lists in 24.1.1 and 24.1.2 is probably
> due to the fact that it does not concern the Iterator class itself, but
> iterator_traits.
I disa
--- Comment #1 from bangerth at dealii dot org 2007-09-20 03:35 ---
Confirmed. We use to error out but don't do any more with gcc4.1.2. icc
does produce an error, but Sun Studio doesn't (though I have other beef
with that latter compiler as well...)
W.
--
bangerth at deal
--- Comment #8 from bangerth at dealii dot org 2007-09-21 02:14 ---
Given that we are twice as fast than our worst versions, I think this
is in fact pretty good. Let's close this PR so that we can focus
on those remaining reports that actually show no progress at all (or
regress
--- Comment #14 from bangerth at dealii dot org 2007-09-21 02:29 ---
We are now again on par with gcc 3.3 in terms of memory use (3.3 uses 298 MB
whereas 4.1 uses 280MB). This is a factor of 2 or 3 less than what we used
to use. We are also about a factor of 2 faster than in the 3.3 and
--- Comment #5 from bangerth at dealii dot org 2007-09-22 03:57 ---
This code:
class Alpha { public: Alpha(); };
static Alpha* a1 = new Alpha;
should definitely not draw a warning because during the initialization
of the variable, the constructor of
--- Comment #3 from bangerth at dealii dot org 2007-09-22 04:10 ---
It seems rather hard to diagnose this. If you change the ABI by using
a floating point representation using a different size of builtin types,
you probably have to build all libraries that you link with with the same
--- Comment #2 from bangerth at dealii dot org 2007-09-22 04:14 ---
(In reply to comment #1)
> What I can find that supports rejecting the code is:
>
> 3.4.3(1) "Qualified name lookup":
>
> "If the name found is not a class-name (clause 9) or namespace-n
--- Comment #1 from bangerth at dealii dot org 2007-09-22 04:32 ---
It is true that both icc and sunCC compile the code both without and with
the declaration of the class Wx, whereas we don't in the former case.
Will have to investigate some more some other time...
W.
--
ban
--- Comment #3 from bangerth at dealii dot org 2007-09-23 16:56 ---
(In reply to comment #2)
> This is not a bogus escape, just extraneous.
Uh, what exactly do you mean? This code is not valid:
---
char *p = \"abc\";
---
Neither should the one qu
--- Comment #1 from bangerth at dealii dot org 2007-09-23 17:07 ---
I get the same output
(gdb) ptype foo
type = int (Obj &)
for all compilers I tried here, i.e. gcc versions 2.95, 3.2.3, 3.3.6, 3.4.6
and 4.1.2. This is with gdb 6.5.
On the other hand, when using icc10 and
--- Comment #3 from bangerth at dealii dot org 2007-09-23 17:13 ---
Confirmed indeed. Core DR 20 added the following text to 12.8/15:
This elision of copy operations is permitted in the following
circumstances (which may be combined to eliminate multiple copies):
-- in
--- Comment #3 from bangerth at dealii dot org 2007-09-23 17:20 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status
--- Comment #2 from bangerth at dealii dot org 2007-09-23 18:09 ---
This indeed looks like a bug. Take this:
-
#include
namespace M {
struct A {};
using std::distance;
}
namespace N
{
template struct S {};
class Q : S {};
int distance(Q,Q);
}
int i
--- Comment #3 from bangerth at dealii dot org 2007-09-23 18:23 ---
This actually turns out to be a serious bug in several different ways.
Here's self-contained code:
---
namespace X {
template struct H { typedef typename T::type type; };
template typename H:
--- Comment #4 from bangerth at dealii dot org 2007-09-23 18:29 ---
I can't seem to produce a wrong-code bug with this -- it appears that gcc
produces the error while investigating the overload set. If I make the
declaration of X::foo work for N::Q, then gcc apparently still do
--- Comment #2 from bangerth at dealii dot org 2007-09-23 19:44 ---
icc (and EDG-based compiler) accepts this code, but sunCC rejects it
as ambiguous.
I don't know off the top of my head who's right and who is not, but
I suspect that it would be gcc and icc who are
--- Comment #6 from bangerth at dealii dot org 2007-09-23 20:57 ---
(In reply to comment #5)
> This looks related to PR17410.
Uh, is this really the one you meant? PR 17410 is about template template
parameters and nested types, neither of which are at hand here...
W.
--
h
--- Comment #4 from bangerth at dealii dot org 2007-09-24 03:52 ---
It's only a diagnostic problem: the template type 'int' in Tag::type
is non-deductible, so the compiler can't find the primary template. The
code in therefore in fact invalid. You can make it
--- Comment #5 from bangerth at dealii dot org 2007-09-24 03:58 ---
Appears fixed now.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #4 from bangerth at dealii dot org 2007-09-24 14:30 ---
My reasoning would be that in the call d%g, the type of the two
expressions are 'double&' and 'A&'. So to call the user-defined
operator%, only the first argument has to be converted t
--- Comment #8 from bangerth at dealii dot org 2007-09-24 18:57 ---
(In reply to comment #7)
> Actually, I've fixed several of those in the past few weeks.
I think this very much appreciated fact was what caused Richard to CC:
you on this PR :-)
--
http://gcc.gnu.org/
--- Comment #24 from bangerth at dealii dot org 2007-09-24 22:07 ---
Since the original issue is resolved and the audit trail of the bug already
very long, I'll close this PR. If you feel that the missed optimization
isn't addressed yet, please open a new report with this
--- Comment #12 from bangerth at dealii dot org 2007-09-25 04:22 ---
(In reply to comment #11)
> Here is what the C++ standard says about linkage:
> A template name may have linkage (3.5). A template, a template explicit
> specialization (14.7.3), or a class
> temp
--
bangerth at dealii dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33558
--- Comment #4 from bangerth at dealii dot org 2007-09-26 19:41 ---
(In reply to comment #3)
> OK. Now there are tests for all of algorithms for defaultconstructable. As per
> 20.1, this is not required for template arguments unless the standard
> explicitly notes it.
Yay, t
--- Comment #12 from bangerth at dealii dot org 2007-09-27 04:06 ---
(In reply to comment #11)
> /usr/include/c++/4.2.1/bits/cpp_type_traits.h:346: error: expected identifier
> before ‘__is_pod’
__is_pod is only implemented on mainline, not 4.2.1.
W.
--
http://gcc.g
--- Comment #4 from bangerth at dealii dot org 2007-10-01 01:10 ---
On big files, this is what can happen with optimized builds...
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-10-01 17:16 ---
For once a real floating point bug. In this code
double p = 0.422244 * f[a.e];
if (f[0] < p)
with a.e=1, f[1]=0.285433, we should calculate p=0.285433. Since
f[0]=0.0461109, we shouldn't enter the i
--- Comment #3 from bangerth at dealii dot org 2007-10-02 22:08 ---
Still present. I know I should know better, but I too ran into this knife
just now and couldn't figure out what was going on for 10 minutes before I
remembered. The error message is really not very helpful.
--- Comment #5 from bangerth at dealii dot org 2007-10-02 23:29 ---
(In reply to comment #4)
> I chose to use ->* not .* because otherwise you get (*pmf) which doesn't
> help either!
You could leave a space around either of the two operators.
W.
--
http
--- Comment #9 from bangerth at dealii dot org 2007-10-03 00:03 ---
Now we only need someone to test the patch and a diagnostic maintainer to
approve...
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-10-03 14:48 ---
Confirmed, a regression introduced by the new parser in 3.4.0.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-10-04 18:41 ---
Why should gettid be in namespace std? It's not a standard C++ function,
so the header file declares it to be in the global namespace.
W.
--
bangerth at dealii dot org changed:
What|Re
--- Comment #2 from bangerth at dealii dot org 2007-10-04 18:46 ---
Yes. I believe there may also be another report about the same problem.
W.
*** This bug has been marked as a duplicate of 11764 ***
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #8 from bangerth at dealii dot org 2007-10-04 18:46 ---
*** Bug 33659 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #7 from bangerth at dealii dot org 2007-10-08 14:56 ---
I've just found a number of other places where currently a VLA
is used and we consequently get a warning with current sources if
using the right flags. These are:
quicksort.h:68
multiway_mergesort.h:142
Benjamin,
--- Comment #10 from bangerth at dealii dot org 2007-10-08 19:15 ---
Created an attachment (id=14323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14323&action=view)
diffs to multiway_mergesort.h and quicksort.h
The attached diffs appear to do it for me.
W.
--
--- Comment #12 from bangerth at dealii dot org 2007-10-08 22:25 ---
I'm sorry, but I don't have a writable account any more. Can you do the
checkin for me?
Thanks
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
--- Comment #6 from bangerth at dealii dot org 2007-10-08 22:28 ---
(In reply to comment #5)
> Wolfgang, this should be fixed now.
Yes, I verified it this morning and it was ok -- thanks for the prompt
work in that! Should I close this PR now?
The only bug that currently st
--- Comment #8 from bangerth at dealii dot org 2007-10-09 03:43 ---
(In reply to comment #6)
> And the order is still undefined between them, does not matter if it is a
> shared library or otherwise.
It is true that the standard only talks about the order of initialization
withi
--- Comment #10 from bangerth at dealii dot org 2007-10-09 14:53 ---
If it's a request to improve the AIX linker, should we even keep this PR
open?
David, as a sidenote (because you're at IBM), this is the sort of thing that
makes AIX such an unpopular target to do developm
--- Comment #12 from bangerth at dealii dot org 2007-10-09 15:18 ---
(In reply to comment #11)
> The problem *could* be solved in GCC, so it probably is worth retaining the
> PR.
OK.
> AIX Brand is much more likely to respond to a customer requirement than a
> request
--- Comment #8 from bangerth at dealii dot org 2007-10-09 18:48 ---
Fixed, thanks y'all!
--
bangerth at dealii dot org changed:
What|Removed |Added
S
--- Comment #9 from bangerth at dealii dot org 2007-10-09 20:51 ---
(In reply to comment #8)
> Wolfgang, please verify and fix if true.
Already under way :-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
--- Comment #2 from bangerth at dealii dot org 2007-10-10 01:07 ---
By the way, here is finally also an example that definitely should
compile due to Koenig lookup:
-
#include
#include
#include
void f () {
std::vector boundary_indicators;
transform
--- Comment #4 from bangerth at dealii dot org 2007-10-10 01:12 ---
(In reply to comment #3)
> Wolfgang, I think some of this is fixed, and for the rest (comment #2), there
> is another bug report (33490) that is focused just on that.
>
> Is my understanding correct?
I be
--- Comment #5 from bangerth at dealii dot org 2007-10-10 01:13 ---
I meant to close this one, as it appears fixed.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-10-12 12:52 ---
It's not the parentheses or the greater-than sign, but the cast
that triggers the error. I will have to look up whether a cast
is allowed here. For reference, icc accepts the code.
W.
--
bangerth at dealii do
--- Comment #4 from bangerth at dealii dot org 2007-10-12 15:21 ---
(In reply to comment #3)
> (I'm told that) these two function-style casts compile fine on 4.2.1:
>
> template
> struct A {
> };
>
> A y;
> A z;
Uh, indeed, I see. This is weird indeed. S
--- Comment #7 from bangerth at dealii dot org 2007-10-12 15:16 ---
This used to be a GCC extension in the old days, which may explain
why it isn't rejected by default. I believe it was deprecated several
releases ago, you may find something to that effect in release notes.
--- Comment #2 from bangerth at dealii dot org 2007-10-12 13:04 ---
The rule for template non-type arguments of integral type is 14.3.2/1:
1 A template-argument for a non-type, non-template template-parameter
shall be one of:
-- an integral constant-expression of integral or
--- Comment #12 from bangerth at dealii dot org 2007-10-18 18:46 ---
Yes, sorry. I meant to report of course that I believe that it works now.
Thanks for your work!
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
--- Comment #4 from bangerth at dealii dot org 2007-10-19 23:54 ---
This is the shortest I can come up with:
--
template
struct __attribute__((visibility("default"))) List {};
int bar(List args);
bool test(const List &);
int i = bar(List());
bool t
--- Comment #1 from bangerth at dealii dot org 2007-10-20 23:36 ---
The code should be invalid precisely because this is also invalid:
---
template struct A;
void foo()
{
A<0>;
}
---
g/x> c++ -c x.cc
x.cc: In function 'void foo()&#
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:35
---
This seems to work with the latest version I have, which is from 20050130.
I don't know what's going on...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:37
---
It also seems to be working with a snapshot from yesterday that I had on
another machine. Andrew, can you double-check with something newer?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20241
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:47
---
Kriang is our resident expert on this. A shorter testcase is this:
---
class C;
namespace NS {
class A {
friend class C;
};
}
using namespace NS;
class C {};
C c
--
What|Removed |Added
Summary|incorrect error: class has |ambiguity with friend name
|not been declared |injection and using
--- Additional Comments From bangerth at dealii dot org 2005-02-28 15:53
---
I believe the code is invalid: you try to do a partial specialization of
a member function, but there is no such thing -- you need to use an overload
instead. To me this looks like an accept-invalid. Here&#
--- Additional Comments From bangerth at dealii dot org 2005-03-02 00:04
---
You can't access a floating point variable through a pointer to integer.
Read up on -fstrict-aliasing, or its negative -fno-strict-aliasing.
W.
--
What|Removed |
--- Additional Comments From bangerth at dealii dot org 2005-03-02 19:24
---
The problem with the compiler not warning about these cases is that it is
perfectly legal to cast a double* to an int* -- the problem is that it is
not legal to access a double through an int*, but to flag
--- Additional Comments From bangerth at dealii dot org 2005-03-02 21:54
---
Correct. The class without inheritance doesn't need a constructor
since objects of this type can be initialized using a brace-enclosed
list. The class with inheritance is not POD, so it can't be i
--- Additional Comments From bangerth at dealii dot org 2005-03-02 23:03
---
This is indeed a diagnostic problem: the access is ambiguous, but instead
of saying so gcc chooses to mention that there is no such name at all. This
happens in many places, and I believe that there must be
--- Additional Comments From bangerth at dealii dot org 2005-03-03 14:39
---
I think gcc is right, and icc rejects the code with an almost exact same
error message.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-03 17:00
---
That's correct, but that's a dup of PR 16859.
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:05
---
Here's another very nice example from PR 20313:
-
template struct s;
template s::s(int j) {}
-
Note that the definition of the constructor is invalid be
--- Additional Comments From bangerth at dealii dot org 2005-03-04 15:15
---
This seems to be more a problem of precompiled headers on solaris than
anything else...
W.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-06 21:37
---
I think the whole idea of second-guessing what a user might have meant when
he misspelled an option is debatable. I personally am of the opinion that
this should yield an error or a warning, but that we
--- Additional Comments From bangerth at dealii dot org 2005-03-10 19:55
---
This is a duplicate of a good number of other PRs. I don't have the time
right now to find them, though...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20401
--- Additional Comments From bangerth at dealii dot org 2005-03-11 14:50
---
Confirmed, with all gcc versions I have on my system. Here's what icc says:
g/x> icc -Xc -ansi -c x.cc
x.cc(15): error: "E" has already been declared in the current s
--- Additional Comments From bangerth at dealii dot org 2005-03-14 16:25
---
The place to look at is 12.6.2/2:
2 Names in a mem-initializer-id are looked up in the scope of the
constructor's class and, if not found in that scope, are looked up in
the scope conta
--- Additional Comments From bangerth at dealii dot org 2005-03-15 18:15
---
Created an attachment (id=8393)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8393&action=view)
Preprocessed sources, not reduced
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20485
--- Additional Comments From bangerth at dealii dot org 2005-03-20 22:46
---
IIRC, this was intentional because people had a habit of writing RCS
"$ID:" strings at the top of files and wanted to find them again in
the executable to identify which files exactly were linke
--
What|Removed |Added
Summary|[4.1 Regression] werid error|[4.1 Regression] weird error
|message after a parse error |message after a parse error
http
--- Additional Comments From bangerth at dealii dot org 2005-03-21 22:05
---
I'm absolutely positive this is a duplicate of a fair number of other PRs,
though I can't find one with a 20 second search. PR 13979 may be one, but
doesn't have a really short testcase so I
--- Additional Comments From bangerth at dealii dot org 2005-03-21 22:17
---
Here's a small testcase:
struct B {};
struct D : B {};
struct S {
int foo(B* & taskData);
};
int i = S().foo((D*)0);
-
We get these messages, the one
--- Additional Comments From bangerth at dealii dot org 2005-03-23 18:53
---
Intuitively, C++ treats unnamed enums differently than named ones, because
in templates the function/class name has to be mangled, and will contain
the name of the template arguments. If the template argument
--- Additional Comments From bangerth at dealii dot org 2005-03-23 19:24
---
That has been subject to discussion (i.e. whether the attempt to use an
unnamed enum as a template argument should just silently fail as a
substitution failure). However, it has been decided that this is a
--- Additional Comments From bangerth at dealii dot org 2005-03-23 21:56
---
Related PRs are: PR 19404, and in particular PR 17413. The latter is the one
I was thinking of.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
x27;t quite so obvious. What
I get is this:
g/x> /home/bangerth/bin/gcc-4*/bin/c++ -c a.cc
a.cc:2: error: ?void B::f()? and ?void B::f()? cannot be overloaded
Note that it doesn't show where the attempt to overload happens, it only shows
the original place. That's bad diagn
--- Additional Comments From bangerth at dealii dot org 2005-03-25 20:12
---
I should add that it doesn't matter whether you use old- or new-style
using declarations:
B::f;
B::f;
and
using B::f;
using B::f;
yield the same results.
W.
--
http://gcc.gnu.org/bug
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:53
---
Well, I wanted to give an "inuitive" reasoning.
On the other hand, how do you propose to make up a unique name if an
unnamed enum is used in two different translation units as a template
argu
--- Additional Comments From bangerth at dealii dot org 2005-03-26 22:57
---
Giovanni, in your example in comment #27, you get this:
>Patched:
>test.cc: In member function 'void A::foo() [with T = int]':
>test.cc:14: instantiated from here
>test.cc:9: err
--- Additional Comments From bangerth at dealii dot org 2005-03-28 15:06
---
Yes, there are multiple PRs in the database about diagnostics when people
forget the semicolon at the end of a struct or class declaration. There are
also examples in these PRs that show why this case is so
--- Additional Comments From bangerth at dealii dot org 2005-04-08 19:38
---
This is duplicate of PR 99.
*** This bug has been marked as a duplicate of 99 ***
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-04-08 19:38
---
*** Bug 20906 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
This little piece of code here
-
template
void test ()
{
double d;
double mu = 1;
for (unsigned int i=0; i ();
-
ICEs with gcc3.4.4pre (and apparently all older versions of the 3.4.x branch I
have):
deal.II/tests> /ices/bangerth/tmp/build-gcc-3.4/gcc-inst
--- Additional Comments From bangerth at dealii dot org 2005-04-13 15:29
---
Note that it isn't related to PR 19899, even though the failure seems similar.
I should also note that the ICE happened with a compiler that had checking
enabled.
If checking is disabled, we simply get
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:29
---
A::foo_ is not template-dependent, so it is looked up and bound at the time
of template definition, not at instantiation time. Because template-dependent
base classes are not visible at the time, the access
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:31
---
The unqualified name Foo is looked up within the class hierarchy, and finds
the name of the base class.
W.
--
What|Removed |Added
301 - 400 of 1203 matches
Mail list logo
