http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60190
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231
--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Feb 18 07:45:39 2014
New Revision: 207836
URL: http://gcc.gnu.org/viewcvs?rev=207836&root=gcc&view=rev
Log:
2014-02-18 Janus Weil
PR fortran/60231
* resolve.c (ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 18 07:32:17 2014
New Revision: 207835
URL: http://gcc.gnu.org/viewcvs?rev=207835&root=gcc&view=rev
Log:
PR driver/60233
* config/i386/driver-i386.c (host_detect_local_cpu)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60252
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 18 07:23:51 2014
New Revision: 207834
URL: http://gcc.gnu.org/viewcvs?rev=207834&root=gcc&view=rev
Log:
PR driver/60233
* config/i386/driver-i386.c (host_detect_local_cpu):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Tue Feb 18 07:19:46 2014
New Revision: 207833
URL: http://gcc.gnu.org/viewcvs?rev=207833&root=gcc&view=rev
Log:
PR driver/60233
* config/i386/driver-i386.c (host_detect_local_cpu):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60253
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60254
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60257
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60251
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #22 from Jakub Jelinek ---
So, shall we just apply #c15 here?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60250
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60257
Bug ID: 60257
Summary: Incorrect column number and confusing message in
-Woverride-init
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960
--- Comment #9 from Andrey Belevantsev ---
Author: abel
Date: Tue Feb 18 05:41:29 2014
New Revision: 207832
URL: http://gcc.gnu.org/viewcvs?rev=207832&root=gcc&view=rev
Log:
PR rtl-optimization/58960
* haifa-sched.c (alloc_global_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60220
--- Comment #3 from harmeeksingh at gmail dot com ---
It still does not vectorise after adding the recomended flag. But rewriting the
code the following way does.
This is a bizare behavioir . My tests show that this is not an issue of gcc
rewriti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
--- Comment #2 from Andrew Pinski ---
Well that is because strcpy(s,s) is optimized away as it is a nop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
--- Comment #1 from Chengnian Sun ---
If the call is to a user-defined function, then gcc warns. I cannot see why
"strcpy" is special.
$: cat s.c
extern void p(const char*);
void f(void) {
char* s;
p(s);
}
$: gcc-trunk -Wuninitialized s.c -c
alized s.c -c
s.c:4:10: warning: variable 's' is uninitialized when used here
[-Wuninitialized]
strcpy(s, s);
^
s.c:3:10: note: initialize the variable 's' to silence this warning
char* s;
^
= NULL
1 warning generated.
$: gcc-trunk --version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255
Bug ID: 60255
Summary: Deferred character length variable at (1) cannot yet
be associated with unlimited polymorphic entities
Product: gcc
Version: 4.9.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #13 from algrant at acm dot org ---
I see what you mean - there is a race if threadB reads the data when the
flag is not set, i.e. in the case when the read value is never used.
Moving the read of data after the test (as in the fragment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60254
Volker Reichelt changed:
What|Removed |Added
Known to work||4.3.0, 4.4.0, 4.5.0, 4.6.0
Target Mil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60254
Bug ID: 60254
Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with non-const
expression in static_assert
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60253
Volker Reichelt changed:
What|Removed |Added
Known to work||4.5.0, 4.6.0
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60253
Bug ID: 60253
Summary: [4.7/4.8/4.9 Regression] ICE passing class object
through ellipsis (...)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60252
Volker Reichelt changed:
What|Removed |Added
Known to work||4.5.0
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60252
Bug ID: 60252
Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with invalid
variable-length array in lambda parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60251
Volker Reichelt changed:
What|Removed |Added
Known to work||4.5.0, 4.6.0, 4.7.0, 4.8.0
Target Mil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60251
Bug ID: 60251
Summary: [4.9 Regression] [c++11] ICE capturing variable-length
array
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60250
Bug ID: 60250
Summary: [4.9 Regression] [c++1y] ICE using lambda for array
size
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60250
Volker Reichelt changed:
What|Removed |Added
Known to work||4.8.0
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
Bug ID: 60249
Summary: [c++11] Compiler goes into semi-infinite loop with
wrong usage of user defined string literals
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #9 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #12 from torvald at gcc dot gnu.org ---
(In reply to algrant from comment #11)
> Where do you get that this is racy if the access to data is not atomic?
In threadB(), you do:
f = flag.load(std::memory_order_consume);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60248
Volker Reichelt changed:
What|Removed |Added
Known to work||4.5.0, 4.6.0
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60248
Bug ID: 60248
Summary: [4.7/4.8/4.9 Regression] ICE specializing variadic
template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60247
Bug ID: 60247
Summary: AVR ATxmega C++ constructor startup in libgcc.S causes
boot loop
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60195
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197
--- Comment #4 from Marek Polacek ---
Ah, right, similarly for:
int
foo (void)
{
int i;
i = (_Cilk_spawn foo ()) + 1;
return i;
}
I don't know whether these are valid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #4 from Bernd Edlinger ---
hmm...
I just looked at PR#52229.
At least on PowerPC many more loops are not vectorizable.
because of unaligned access.
Jakub's last comment there is that the xfail
should be based on the vect_hw_misaling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197
--- Comment #3 from Volker Reichelt ---
Well, the code also crashes, if I move it out of the return statement:
=
int foo()
{
int i = (_Cilk_spawn foo()) + 1;
return i;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235
--- Comment #7 from Mehdi Amini ---
Yeah I can declare it inline, indeed I already did, I was just considering it a
workaround for a "missing compiler optimization" ;-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235
--- Comment #6 from Jakub Jelinek ---
Clang doesn't care about lots of things.
Anyway, why don't you make the specialization inline?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #16 from Jan Hubicka ---
I am also seeing this in libreoffice. We devirtualize into destructor of
ZCodec that is a base class of other codec used in the library, but the library
is not linking with its implementation.
I believe it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146
--- Comment #4 from Jakub Jelinek ---
I've tried:
--- pt.c.jj32014-02-12 17:46:47.0 +0100
+++ pt.c2014-02-17 19:22:36.617413387 +0100
@@ -13057,10 +13057,28 @@ tsubst_omp_for_iterator (tree t, int i,
init = TREE_OPERAND (init, 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350
--- Comment #12 from owner at bugs dot debian.org ---
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246
Bug ID: 60246
Summary: Emit debug info for explicit template instantiation
definitions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225
--- Comment #3 from Paolo Carlini ---
Thus, it seems to me that to have a consistent literal_type_p /
ensure_literal_type_for_constexpr_object pair we should use strip_array_types
in the latter too. The below passes testing, for example:
Index: s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146
--- Comment #3 from Jakub Jelinek ---
decl in this case in tsubst_omp_for_iterator is i, and init is DECL_EXPR i, i
has DECL_INITIAL set to the function call. RECUR on both of these will tsubst
the initializer before the loop, rather than in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235
--- Comment #5 from Mehdi Amini ---
(In reply to Jakub Jelinek from comment #2)
> The specialization is a regular function, not comdat, thus it is not
> appropriate to inline it at -O2 -fpic, only -O3 is inlining functions
> regardless to whether
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #7 from Marc Glisse ---
(In reply to N Schaeffer from comment #6)
> Is there somewhere a rationale for not making isnan() find NaN's with
> -ffinite-math-only ?
finite-math-only is basically a promise that isinf and isnan always retur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245
--- Comment #2 from Florent Hivert ---
Sorry ! The version I submitted is not the most reduced. Here is a version not
using vectors:
constexpr int Apply(const int in, int (*f)(const int&)) { return f(in); }
using Foo = int;
static constexpr int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235
--- Comment #4 from Jan Hubicka ---
Even at -O3 we inline only functions that either can not be interposed (i.e.
static or -fno-pic) or are known to be same everywhere (comdat and functions
declared inlined). I was considering command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245
--- Comment #1 from Florent Hivert ---
Created attachment 32155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32155&action=edit
preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245
Bug ID: 60245
Summary: Template static function not accepted as constexpr
parameter
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58545
Georg-Johann Lay changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 60040, which changed state.
Bug 60040 Summary: AVR: error: unable to find a register to spill in class
'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
What|Removed |Adde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076
Georg-Johann Lay changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60227
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60224
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #6 from N Schaeffer ---
-fno-builtin-isnan is also interesting, thanks.
Is there somewhere a rationale for not making isnan() find NaN's with
-ffinite-math-only ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244
Bug ID: 60244
Summary: GCC-trunk rev.207809, Segmentation fault when
executing ".../xgcc -dumpspecs"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242
cerealguy at yandex dot ru changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from ce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #6 from Dominique d'Humieres ---
While preparing a test case, I have been hit by another snag!-(
With the trunk and 4.8, the following test
write(*,"(en15.2)") 98765.
write(*,"(en15.3)") 9876.5
write(*,"(en15.1)") 987.65
write(*,"(en1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #1 from Richard Biener ---
-O2 -fno-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
Bug ID: 60243
Summary: IPA is slow on large cgraph tree
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234
--- Comment #7 from janus at gcc dot gnu.org ---
I think it should be possible (and preferable) to always defer the building of
the vtab, and not only partially as in comment 6. Will try to do that ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
Adam Hirst changed:
What|Removed |Added
CC||adam at aphirst dot karoo.co.uk
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #3 from Bernd Edlinger ---
ERROR: gfortran.dg/vect/pr32380.f -O : error executing dg-final: syntax error
in target selector "! target vect_call_sqrtf"
what is the right syntax here??
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60234
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Unfortunately the combination fails on proc_ptr_comp_37 in the testsuite.
To fix this, another hunk in class.c is needed, so that the patch becomes:
Index: gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133
Richard Earnshaw changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #2 from Bernd Edlinger ---
(In reply to Richard Biener from comment #1)
> Does ARM have a builtin-vectorized-function hook that handles sqrtf? If not,
> then that's expected.
>
Yes, it does have a builtin-vectorized-function which d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60242
Bug ID: 60242
Summary: incorrect optimization of code with inline assembly
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60241
Bug ID: 60241
Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2617
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Feb 17 12:46:52 2014
New Revision: 207823
URL: http://gcc.gnu.org/viewcvs?rev=207823&root=gcc&view=rev
Log:
2014-02-17 Janus Weil
PR fortran/55907
* resolve.c (b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25975
--- Comment #11 from Richard Biener ---
*** Bug 60237 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #1 from Richard Biener ---
Does ARM have a builtin-vectorized-function hook that handles sqrtf? If not,
then that's expected.
Please adjust the expected number of vectorizations with vect_call_sqrt like
! { dg-final { scan-tree-dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> The specialization is a regular function, not comdat, thus it is not
> appropriate to inline it at -O2 -fpic, only -O3 is inlining functions
> regardless to wheth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60224
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60227
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
Richard Biener changed:
What|Removed |Added
Keywords||EH
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60220
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60231
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> This draft patch fixes the ICE:
... and regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60219
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
1 - 100 of 148 matches
Mail list logo
