http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
--- Comment #13 from Manuel López-Ibáñez 2013-01-21
11:14:43 UTC ---
In fact, the nicest solution would be to investigate how much of Ian's document
is already duplicated in the GNU binutils sources:
http://www.gnu.org/savannah-checkouts/gnu/au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56048
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||net, manu at gcc dot
||gnu.org
Summary|last reconfirmed : now |[bugzilla] last reconfirmed
||: now
--- Comment #2 from Manuel López-Ibáñez 2013-01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56048
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Bug #: 56084
Summary: poor error recovery for missing ";"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Man
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #3 from Manuel López-Ibáñez 2013-01-23
17:02:02 UTC ---
> (Separately, I'm investigating whether there's some way to reduce the output
> when an invalid ostream operation is done, because the sheer number of
> overloads of operator<<
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #4 from Manuel López-Ibáñez 2013-01-23
17:05:14 UTC ---
BTW, what is the difference between deduction and substitution?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #5 from Manuel López-Ibáñez 2013-01-23
17:10:58 UTC ---
Of course, the color output makes much easier to spot the "note:". And the use
of a common prefix "note: candidate function..." or "note: candidate
template..." also makes easie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #7 from Manuel López-Ibáñez 2013-01-23
17:31:21 UTC ---
Strange. In the GCC farm and without any customization, clang uses gray for the
note. I have seen presentations where it also uses this color scheme. I don't
know if they have s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #9 from Manuel López-Ibáñez 2013-01-24
18:39:18 UTC ---
> During original gimplification, I can understand the OR_HERE (aka
> input_location) part there, or in passes that maintain input_location.
I thought gimplification happens af
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #11 from Manuel López-Ibáñez 2013-01-24
20:49:33 UTC ---
(In reply to comment #10)
>
> Input_location should only be used from parsing. Other places reuse the
> variable and those happen to eventually pick up stale values, such as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #13 from Manuel López-Ibáñez 2013-01-25
11:43:37 UTC ---
(In reply to comment #12)
> Created attachment 29272 [details]
> gcc48-pr56094.patch
>
> input_location is used heavily in the gimplifier, gimplify_expr sets it from
> the exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061
--- Comment #6 from Manuel López-Ibáñez 2013-01-30
11:29:02 UTC ---
(In reply to comment #3)
> Does it make sense to allow "-O0 -flto" at all?
Answering myself, the docs have this example:
Additionally, the optimization flags used to compile i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
--- Comment #16 from Manuel López-Ibáñez 2013-01-30
18:18:35 UTC ---
(In reply to comment #15)
> I'm speaking as one of Code::Blocks' developers:
> If you implement this we'll for sure use it, because we have many complaints
> similar to the one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56153
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to janus from comment #4)
> This seems very inconsistent: All three calls involve an invalid flag, but
> the diagnostics is very different for each of them (it's particularly bad
> that the se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to janus from comment #3)
> I guess practically all occurrences of "gfc_warning (0, ..." need to be
> transformed, or are there cases where the zero is legitimate?
Most warnings don't have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #19)
> Is it time to close this one out as fixed?
with gcc HEAD 6.0.0 20160127 and the testcase in comment #12, I get:
prog.cc: In member function 'void B::bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20906
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|excessive diagnostic|excessive diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
--- Comment #21 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #19)
> /tmp/test2.cc:9:24: error: return-statement with a value, in function
> returning 'void' [-fpermissive]
> return P->bar() + *P;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20906
--- Comment #5 from Manuel López-Ibáñez ---
With a slight change in the parse tree, we get a much better message.
prog.cc:3:38: error: wrong number of template arguments (0, should be 1)
template void foo::pop(bar<>&, int) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24375
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544
Manuel López-Ibáñez changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #4)
> Reverting one minor part of those changes fixes both of the PRs though:
> --- gcc/c-family/c-pragma.c.jj2016-01-15 21:57:00.0 +0100
> +++ gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #0)
> warns about deprecated use, while before that we didn't warn.
It would be useful to see the locations in the output (and whether the warning
uses %q+), sin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #8 from Manuel López-Ibáñez ---
So input_location does not point to foo but to column 1, then the expansion
location of the pragmas is the closing paren because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817#c3
In terms of exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #8)
> then the second one doesn't work. I cannot think a way to make the above
> work properly without breaking something else.
Actually, the history check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #6)
> Related to pr69544. Note that compiling the test with 5.3.0 or trunk (6.0)
> gives now an ICE, r218570 gives the error and r218658 gives the ICE.
Hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #4 from Manuel López-Ibáñez ---
Pre rich locations, it should have looked like
# [name]:[locus]:
#
# some code
# 1
# [name]:[locus2]:
#
# some other code
# 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Component|othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #8)
> This seems a lot of work for big patches. Note that this is not specific to
> gfortran: any one committing a patch should look at the Intel results!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #11)
> I think you need to add a line
>
> ! { dg-options "-pedantic" }
>
> to elemental_optional_args_6.f90 (untested).
I'd suggest to use -Wpedantic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to Stephan Bergmann from comment #18)
> (Also, the problem
> only happens with -O or higher.)
That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
should be able to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Manuel López-Ibáñez from comment #7)
> > Please take this as a humble general suggestion: Fortran maintainers should
> > enforce during patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69605
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #3 from Manuel López-Ibáñez ---
I wonder when/why it started warning, since -Wlogical-op is not new in GCC 6.
This is just a more complex case of PR61534.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #4 from Manuel López-Ibáñez ---
Since EAGAIN and EWOULDBLOCK probably expand from a macro to a constant (or are
they enums? do we track the original form of the enum or only the underlying
value?), this is as hard as:
extern int xxx;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #5)
> Even if we look through macros, I'd actually think we should warn here.
I think we should NOT look through macros. The purpose of the warning is to
catch m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Eric Blake from comment #0)
> However, as shown by the sample code below, gcc 6.0's new warning is
> over-ambitious, and is likely to _cause_ rather than cure user bugs, when
> uninformed u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69612
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69641
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
GCC 5.2
prog.cc:1:5: warning: "/*" within comment [-Wcomment]
/* /* */
^
GCC 6.0
prog.cc:1:0: warning: "/*" within comment [-Wcomment]
/* /* */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #11 from Manuel López-Ibáñez ---
This should be fixed in libcpp, probably in lex.c, but maybe other places also.
A good testcase to start with would be:
/* ñ /* */
/* a /* */
cc1 -Wcomment
prog.cc:1:7: warning: "/*" within comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69664
Manuel López-Ibáñez changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|column info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #16 from Manuel López-Ibáñez ---
You can also just match the locations and the columns with dg-error. Placing
dg-error at the expected lines will match the expected output as explained in
comment 12. Fixing dg-begin-multiline-output f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Manuel López-Ibáñez changed:
What|Removed |Added
Depends on||43486, 61534
--- Comment #9 from M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #6 from Manuel López-Ibáñez ---
Note that it is ok to completely ignore such an invalid line directive and:
line-map.c: file "" left but not entered
should actually be an error or an ICE. As the code says:
/* Depending upon w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to Gerald Pfeifer from comment #10)
> (In reply to Jakub Jelinek from comment #8)
> > if (errno == EAGAIN || (EWOULDBLOCK != EAGAIN && errno == EWOULDBLOCK))
> > could be better workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
Manuel López-Ibáñez changed:
What|Removed |Added
CC||developm...@faf-ltd.com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #7)
> As for the missed -Wuninitialized at -O0, wonder if we couldn't do something
> about it for GCC 7.
Sounds good to me, but perhaps it is better to open a ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60239
Manuel López-Ibáñez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69723
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #7)
> As for the missed -Wuninitialized at -O0, wonder if we couldn't do something
> about it for GCC 7.
Note that people do complain a lot about this case: PR43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69730
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69782
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||2016-02-14
CC||manu at gcc dot gnu.org
Summary|g++ ICE on invalid code on |ICE on invalid code in
|x86_64-linux-gnu in |"cp_lexer_peek_nth_token"
|"cp_lexer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez ---
Probably, when 'typename' became valid here, this code path was not fixed.
Needs further debugging, but should be easy to fix. Not a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69778
--- Comment #2 from Manuel López-Ibáñez ---
Bonus points if instead of creating a useless tree, the error uses %qv to print
the qualifiers, as the C FE does.
CC||manu at gcc dot gnu.org
Summary|feature request: generate a |warn for C++ functional
|warning for C++ functional |cast expression on pointer
|cast expression on pointer |or reference
|or
||manu at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Harald van Dijk from comment #2)
> It's already been fixed.
[...]
> But the comments in PR 60850 note that this may have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
--- Comment #34 from Manue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573
Manuel López-Ibáñez changed:
What|Removed |Added
CC||david at doublewise dot net
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||manu at gcc dot gnu.org
Target Milestone|5.4 |---
Summary|Feature Request,|-Wcovered-switch-default to
|-Wcovered-switch-default to |identify "dead" default
|identify &quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||easyhack
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #27 from Manuel López-Ibáñez ---
(In reply to Mark Wielaard from comment #21)
> Although in C a static const is not really like a #define I suspect that
> there are cases where they are used as such in header files. If that is the
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #7 from Manuel López-Ibáñez ---
Richard, perhaps a less aggressive -Wunreachable-code could be implemented just
after (or while) building the control flow graph?
It would not try to be smart with constant propagation or guessing bran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
--- Comment #6 from Manuel López-Ibáñez ---
Other testcases:
int baz()
{
while(1) {
break;
return 5; // dead
}
do {
continue;
return 6; // dead
} while(0);
return 1;
}
int bax()
{
while(1) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
Manuel López-Ibáñez changed:
What|Removed |Added
CC||mgsergio at yandex dot ru
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
||2016-02-18
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Bernd Edlinger from comment #2)
> in gcc/c-family/c-opts.c:
>
> following cod
++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
Target Milestone: ---
struct s { int x, y; };
short offsets[1] = {
((char*) &(((struct s*)16)->y) - (char *)16), // { dg-message "narrowing" ""
{ target c++11 } }
};
$ g++ pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic, documentation,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Markus Trippelsdorf from comment #9)
> > * Create a new function in diagnostic.c, e.g.,
> >
> > extern diagnostic_t pederror (location_t, int, const char *, ...)
> > ATTRIBUTE_GCC_D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
Manuel López-Ibáñez changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #5 from Manuel López-Ibáñez ---
If you wish to get the warning with -O0, then this is a duplicate of PR43361
(explained in detail here:
https://gcc.gnu.org/wiki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #31 from Manuel López-Ibáñez ---
(In reply to Mark Wielaard from comment #29)
> > > + || filename_cmp (main_input_filename,
> > > +DECL_SOURCE_FILE (decl)) == 0)))
> >
> > Better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16233
Manuel López-Ibáñez changed:
What|Removed |Added
CC||steve.lorimer at gmail dot com
---
||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
Duplicate
*** This bug has been marked as a duplicate of bug 16233 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16233
--- Comment #9 from Manuel López-Ibáñez ---
Very likely, we don't even try to parse this as a template function. We should
first try to parse it as we do now. When that fails, we should try to reparse
it as a template if we have seen <>, if that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 43361, which changed state.
Bug 43361 Summary: missing uninitialized warning without optimization (loop
representation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361
Manuel López-Ibáñez changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
1001 - 1100 of 2545 matches
Mail list logo
