https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
Segher Boessenkool changed:
What|Removed |Added
Known to work||10.0
Summary|[10 regress
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
r278509 exposes this problem (the -fno-common patch). It causes global
variables to be accessed via an anchor.
But now fwprop1 does:
In insn 8, replacing
(mem/c:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #19 from Segher Boessenkool ---
(In reply to Aleksey from comment #16)
> > > It would be helpful if you give the explanation how these options affect
> > > "un-factoring".
> >
> > What options? -fno-reorder-blocks? Those doo the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #8 from Segher Boessenkool ---
I don't think you need lines 4909..4911.
How can we test this? Is there good test coverage for it already?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #11 from Segher Boessenkool ---
Hi Daniel,
(In reply to Daniel Marjamäki from comment #9)
> Problems;
>
> * Code that performs comparison properly gets a warning.
You get a warning if you compare a signed thing to an unsigned thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #9 from Segher Boessenkool ---
Oh, and I think you can drop the
if (!TARGET_ALTIVEC && !TARGET_VSX)
thing? The rest of the code should handle that fine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #15 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #12)
> So, how would you fix the warning for `f`? Many programmers would "fix" it
> with a cast.
>
> Assuming that `s` and `u` can have arbitrary values, here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #16 from Segher Boessenkool ---
(In reply to Eric Gallager from comment #13)
> > Yes. You should not use casts, except in some very specific cases, and
> > most of the uses you see "in the wild" are a bad idea. Sometimes I wonder
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #18 from Segher Boessenkool ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Segher Boessenkool from comment #15)
> > A much better fix is
> >
> > void f1(long s, unsigned long u) { unsigned long su = s; if (su == u)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #13 from Segher Boessenkool ---
Does that work? You cannot put all hard registers in memory I think?
Or do we require that and it is just not documented?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Sure, before that we would punt much earlier at simplification of the
> non-sensical subreg.
We probably should again then?
> I don't mind if simplify_subr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
||2019-11-28
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Nov 28 22:28:59 2019
New Revision: 278821
URL: https://gcc.gnu.org/viewcvs?rev=278821&root=gcc&view=rev
Log:
rs6000: Use memory_operand for all simple {l,st}*brx instructions
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #5 from Segher Boessenkool ---
It's not top priority; it is fine for stage 4, too. Patches welcome.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #21 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #20)
> Ping. Your "much better" code does not work.
I said that this is much better than an explicit cast. It is. And it behaves
identically.
If the user e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #24 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #23)
> > If the user expects C to provide tests for "mathematically different", the
> user has some learning to do.
>
> I believe most users can appreciate th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
||2019-12-11
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
CR0 is volatile in all our ABIs, so this is impossible to support from
a C function without
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-11
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #3 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #2)
> But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before
> branching to LR as the ASM functions do, does it ?
Not at all, no. But e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91534
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #3 from Seghe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #2 from Segher Boessenkool ---
Trying 104 -> 105:
104: r125:SI=zero_extend(r101:SI#0)
REG_DEAD r101:SI
105: r127:SI={(r100:SI!=0)?r125:SI:r79:SI}
REG_DEAD r125:SI
REG_DEAD r100:SI
REG_DEAD r79:SI
Failed to
||2019-12-19
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
I have code to do this for bfp already, so I'll take it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122
--- Comment #2 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 47581 [details]
> gcc10-pr93122.patch
>
> Untested fix. With additional -fno-asynchronous-unwind-tables, it doesn't
> ICE, but just emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122
--- Comment #3 from Segher Boessenkool ---
Alternatively, we should generate the patterns we have by name, not indirectly
like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #7 from Segher Boessenkool ---
This is related to the compiler saving the return address for noreturn
sibcalls, like in
void g(void) __attribute__((noreturn));
void f(void) { g(); }
Maybe we should have an option like "-fimprove
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
For example,
nestfunc-1.c: In function 'f':
nestfunc-1.c:22:1: warning: control reaches end of non-void function
[]8;;https://gcc.gnu.org/onlinedocs/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93168
--- Comment #1 from Segher Boessenkool ---
The actual control stuff is eaten by bugzilla, but it makes just as little
sense like this. There is an escape before the ] I think, but it messes up
the display (in different and interesting ways depen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #59 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #58)
> (In reply to Jeffrey A. Law from comment #39)
> > Failed to match this instruction:
> > (set (reg/i:DI 0 x0)
> > (ior:DI (and:DI (reg:DI 95)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #3 from Segher Boessenkool ---
Okay, I'll bite.
Which of the functions/macros in ppu_intrinsics.h would you find useful?
Have you checked whether the implementation is good for your purpose, or
if they even are correct (the cntlz one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #6 from Segher Boessenkool ---
(In reply to Matt Emmerton from comment #4)
> The intrinsics that we would find useful, having used them as provided by
> the IBM XL C/C++ compiler, are the following:
>
> __sync()
> __isync()
> __lwsyn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #7 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> >the cntlz ones are not, for example
>
> :) It has been a long time since I touched this but I would not doubt I
> messed up this too.
It's nastiness in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #5 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #4)
> >Linux system calls and Linux VDSO calls
>
> System calls, I can understand But why is it required by VDSO calls too?
> That seems backwards and also mea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> This happens during combine. If whether the comparison raises exception or
> not is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the
> p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93172
--- Comment #3 from Segher Boessenkool ---
Why should it be limited that way? simplify_rtx does not / should not care
about peculiarities of a certain architecture or microarchitecture.
A transform like this would be a good idea I think, and wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
--- Comment #2 from Segher Boessenkool ---
(In reply to Martin Liška from comment #1)
> @Segher: Can you please take a look?
Yes, tomorrow, when I am back from vacation :-)
Confirmed, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93393
--- Comment #5 from Segher Boessenkool ---
It is a backend issue that we cannot solve properly without solving much bigger
generic problems first. See the BoF at last year’s cauldron. Without fixing
that first, doing signaling floats regresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
--- Comment #3 from Segher Boessenkool ---
The code at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/rs6000/rs6000.c;h=fc36bb6714b2a4c922e903e2ebe333c6bdaeefcd;hb=HEAD#l9229
does not treat this case specially, but it should.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #10 from Segher Boessenkool ---
(In reply to Matt Emmerton from comment #9)
> > > __sync()
> > > __isync()
> > > __lwsync()
> >
> > The sync intrinsics need to be tied to some other code. A volatile asm with
> > a "memory" clobber i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #2 from Segher Boessenkool ---
When you want the bits from bit MB to ME (inclusive) set, you can just do
li t,-1
rldic d,T,MB,63-ME
(bit # 0 is the high bit; can also do wrap-around masks this way).
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93157
--- Comment #2 from Segher Boessenkool ---
Someone who can test this should send a patch, and Cc: the Musl OS port
maintainer
(is there one? There should be!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93157
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #7 from Segher Boessenkool ---
Why? Is there any advantage to that? The probability of having a collision
anywhere in the repo is nihil with ten digits already, and anywhere in the
world ever with twelve. Why do we want thirty-two?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93123
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93127
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
--- Comment #3 from Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #13 from Segher Boessenkool ---
You cannot use that from intrinsics. But the target code can do similar of
course, whether or not asm syntax for this exists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #14 from Segher Boessenkool ---
We can use the r10-1234 names in exactly the places we use r123456 before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
--- Comment #3 from Segher Boessenkool ---
So you just use "d", like in
void g(_Decimal128 x) { asm("# %0" :: "d"(x)); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
--- Comment #1 from Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Seghe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #1 from Segher Boessenkool ---
*** Bug 90968 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91116
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
--- Comment #5 from Segher Boessenkool ---
Great :-)
We still should have builtins for this, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #5 from Segher Boessenkool ---
bcdadd works with decimal *integers*; _Decimal128 is decimal *float*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #6 from Segher Boessenkool ---
[ Whoops, hit enter. ]
We need to have a C type for decimal integer before we can use that at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90977
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 47740 [details]
> gcc10-pr93505.patch
>
> Untested combiner fix. IMHO even when we fix expand_binop we want it
> anyway, because we do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #13 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #11)
> and so I'd say even if we just don't fix expand_binop, this shows an
> optimization opportunity for the rs6000 backend
> if the rotlw instruction only uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
--- Comment #18 from Segher Boessenkool ---
PR93512 is marked as enhancement, but if we don't fix this it is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #2 from Segher Boessenkool ---
Of course it first tried to do
Failed to match this instruction:
(parallel [
(set (reg:DI 101 [ _9 ])
(ctz:DI (reg/v:DI 98 [ x ])))
(set (reg:DI 100)
(ctz:DI (reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213
--- Comment #2 from Segher Boessenkool ---
I don't know how I reproduced this before, but I cannot any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87213
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #2 from Segher Boessenkool ---
That isn't documentation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512
--- Comment #4 from Segher Boessenkool ---
I said (or I meant, at least) that as far as I see and know, all rotate
instructions on all machines do this truncation. It is of course possible
for targets to write it in RTL that only works for a lim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #4 from Segher Boessenkool ---
Why would that be unlikely? It lengthens the lifetime of that pseudo,
potentially significantly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #5 from Segher Boessenkool ---
IOW, we need hard numbers, not guesstimates :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #7 from Segher Boessenkool ---
What makes that move redundant? I don't see it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #5 from Segher Boessenkool ---
Actually, this is simply wrong.
===
;; Function round_double_uint (round_double_uint, funcdef_no=5, decl_uid=2879,
cgraph_uid=3, symbol_order=2)
round_double_uint (double a)
{
int _4;
double _5;
;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #6 from Segher Boessenkool ---
It is still okay in ppc-round.c.048t.local-fnsummary2 but it is wrong
in ppc-round.c.088t.fixup_cfg3 (the pass immediately after it, at -O2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #7 from Segher Boessenkool ---
Ah, -fdump-ipa-all-all . So it seems like ppc-round.c.072i.icf is what is
wrong; it says
Equals called for: round_float_uint/3:round_float_int/1 with result: true
Equals called for: round_double_uint/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #8 from Segher Boessenkool ---
I confirm this is caused by r278207.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
--- Comment #12 from Segher Boessenkool ---
But it could do just
stw r4,0(r3)
(on LE; and with a rotate first, on BE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #10 from Segher Boessenkool ---
What makes shift amount special at all, for those gimple simplifications?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #12 from Segher Boessenkool ---
Sure, but what makes shift amount special here? This works just fine in
any other expression as well. That is, for unsigned n; for negative numbers
modulo works differently: it returns 0 or negative,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #10 from Segher Boessenkool ---
One of the first things combine tries is
Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #11 from Segher Boessenkool ---
(The original problem I have an idea for -- don't generate a parallel of
two SETs with equal SET_SRC -- but that doesn't handle the new case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #13 from Segher Boessenkool ---
nonzero_bits is not reliable. We also cannot really do what you propose
here, all of this is done for *every* combination.
We currently generate
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The new testcase pr93661.c does not warn.
int f ()
{
unsigned x = 0x;
__builtin_memset (1+(char *) &x, 0, -1); /* { dg-warning "maxim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #16 from Segher Boessenkool ---
It is not the same cost. It reduces the path length.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #17 from Segher Boessenkool ---
That above commit is just a spec special, it doesn't solve anything else,
imnsho.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #18 from Segher Boessenkool ---
Created attachment 47841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47841&action=edit
Patch to treat sign_extend as is_just_move
301 - 400 of 3228 matches
Mail list logo
