https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
--- Comment #5 from Alexander Monakov ---
(In reply to Richard Biener from comment #4)
>
> For the case at hand loading two vectors from the destination and then
> punpck{h,l}bw and storing them again might be the most efficient thing
> to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-*-*
Created attachment 54202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54202=edit
testcase
At le
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For
unsigned short f(unsigned short x, unsigned short y)
{
return x * y;
}
unsigned short g(unsigned short x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229
--- Comment #3 from Alexander Monakov ---
Thank you! I considered this unprofitable for these reasons:
1. As you said, the code grows in size, but the speed benefit is not clear.
2. The transform converts load+add operations in a loop, and
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
In the following example, STV is making a very unprofitable transformation on
trunk, but not on gcc-12:
#include
#include
struct b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209
--- Comment #1 from Alexander Monakov ---
Keeping notes as I go...
Duplicated checks for 'op0' in lower_for are duplicated.
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
It pretends that define_operator_list is commutative when its first member is
NOT commutative:
if (user_id *uid = dyn_cast (id))
{
int res = commutative_op (uid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #16 from Alexander Monakov ---
Draft patch for the sched1 issue:
https://inbox.sourceware.org/gcc-patches/cf62c3ec-0a9e-275e-5efa-2689ff1f0...@ispras.ru/T/#m95238afa0f92daa0ba7f8651741089e7cfc03481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108140
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067
--- Comment #9 from Alexander Monakov ---
*** Bug 108117 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #12 from Alexander Monakov ---
Shouldn't there be another bug for the sched1 issue specifically? In absence of
abnormal control flow, extending lifetimes of pseudos across calls is still
likely to be a pessimization.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
match.pd has multi-pattern matcher 'nop_atomic_bit_test_and_p'.
It expands to ~38 KLOC in gimple-match.cc and ~350 KB in the compiled binary.
There has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #9 from Alexander Monakov ---
(In reply to Feng Xue from comment #8)
> In another angle, because gcc already model control flow and SSA web for
> setjmp/longjmp, explicit volatile specification is not really needed.
That covers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108076
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008
--- Comment #10 from Alexander Monakov ---
Looks similar to PR 107323, but needs explicit -ftree-loop-distribution to
trigger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008
--- Comment #9 from Alexander Monakov ---
I think this is tree-ldist placing memset(sameZ, 0, zPlaneCount) after the
loop, overwriting conditional 'sameZ[i] = true' assignments that happen in the
loop.
For the smaller testcase from comment #6,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #11 from Alexander Monakov ---
Factoring out Lujiazui divider shrinks its tables by almost 20x:
3 r lujiazui_decoder_min_issue_delay
20 r lujiazui_decoder_transitions
32 r lujiazui_agu_min_issue_delay
126 r lujiazui_agu_transitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #10 from Alexander Monakov ---
If anyone is confused like I was, the commit actually includes a testcase, but
the addition is not mentioned in the Changelog. I was sure the server-side
receive hook was supposed to reject such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905
--- Comment #6 from Alexander Monakov ---
Let me add that Clang supports GCC's -fprofile-{generate,use} flags for
compatibility as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905
--- Comment #5 from Alexander Monakov ---
Not sure what you don't like about the inputs, they appear quite reasonable.
Perhaps GCC's estimation of bb frequencies is off (with profile feedback we
achieve good performance).
Georgi: you'll likely
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Alexander Monakov ---
Fixed for gcc-13.
||amonakov at gcc dot gnu.org
--- Comment #3 from Alexander Monakov ---
LLVM does a better job at code layout, and massively wins on the amount of
executed branches (in particular unconditional jumps). With -fdisable-rtl-bbro
gcc achieves a similar performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #26 from Alexander Monakov ---
Sure, the right course of action seems to be to simply document that atomic
types and built-ins are meant to be used on "common" (writeback) memory, and no
guarantees can be given otherwise, because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #24 from Alexander Monakov ---
(In reply to Peter Cordes from comment #23)
> But at least on Linux, I don't think there's a way for user-space to even
> ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #21 from Alexander Monakov ---
(In reply to Michael_S from comment #19)
> > Also note that 'vfnmadd231pd 32(%rdx,%rax), %ymm3, %ymm0' would be
> > 'unlaminated' (turned to 2 uops before renaming), so selecting independent
> > IVs for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #15 from Alexander Monakov ---
I'm confused about the first hunk in the attached patch:
--- a/gcc/tree-vect-slp-patterns.cc
+++ b/gcc/tree-vect-slp-patterns.cc
@@ -1035,8 +1035,10 @@ complex_mul_pattern::matches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107719
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #10 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #9)
> Actually for older cores I think the manufacturers do not care much. I
> still have a working Bulldozer machine and I can do some testing.
> I think in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107715
--- Comment #3 from Alexander Monakov ---
There's a forward dependency over 'c' (read of c[i] vs. write of c[i+1] with
'i' iterating forward), and the vectorized variant takes the hit on each
iteration. How is a slowdown even surprising.
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #8 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #7)
> > 53730 r btver2_fp_min_issue_delay
> > 53760 r znver1_fp_transitions
> > 93960 r bdver3_fp_transitions
> > 106102 r lujiazui_core_check
> > 106102 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #6 from Alexander Monakov ---
With these patches on trunk, current situation is:
nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//' | sort -n
| tail -40
2496 r slm_base
2527 r bdver3_load_min_issue_delay
2746 r
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #8 from Alexander Monakov ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #15 from Alexander Monakov ---
Ah, there will be an mfence after the vmovdqa when necessary for an atomic
store, thanks (I missed that because the testcase doesn't scan for mfence).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #6 from Alexander Monakov ---
Sure, but I was talking specifically about the pattern matching introduced by
that commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #3 from Alexander Monakov ---
Followup patches have been posted at
https://inbox.sourceware.org/gcc-patches/20221101162637.14238-1-amona...@ispras.ru/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
Alexander Monakov changed:
What|Removed |Added
Summary|[13 regression] Numerous|frontends sometimes select
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #13 from Alexander Monakov ---
As for the Fortran testcases, the issue is again caused by the front-end
invoking decl_default_tls_model before assigning DECL_COMMON, this time in
fortran/trans-common.cc:build_common_decl.
So I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #12 from Alexander Monakov ---
ICE on the emutls-3.c testcase isn't related to emutls. Rather, the frontend
invokes decl_default_tls_model before attributes are processed, so the first
time around we miss the 'common' attribute when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #11 from Alexander Monakov ---
I've broken out the C++ issue from comment #10 as PR 107393, thanks for the
testcase. It's a separate issue from emutls and Fortran ICEs on other targets.
: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot gnu.org,
law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #9 from Alexander Monakov ---
Actually, latest results from H.J. Lu's periodic x86_64 tester don't exhibit
such issues either:
https://inbox.sourceware.org/gcc-testresults/20221025065901.6dc0062...@gnu-34.sc.intel.com/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #8 from Alexander Monakov ---
(In reply to Arseny Solokha from comment #7)
> I have it on x86_64-pc-linux-gnu…
Thanks for the info (I assume you don't have any special configure arguments),
but that's surprising, I ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #1 from Alexander Monakov ---
Suggested partial fix for the integer-pipe side of the blowup:
https://inbox.sourceware.org/gcc-patches/4549f27b-238a-7d77-f72b-cc77df8ae...@ispras.ru/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380
Bug 102380 depends on bug 99619, which changed state.
Bug 99619 Summary: fails to infer local-dynamic TLS model from hidden visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99619
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99619
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107250
--- Comment #3 from Alexander Monakov ---
Well, obviously because in one function both 'f' and 'tmp' are live across the
call, and in the other function only 'f' is live across the call. The
difference is literally pushing one register vs. two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #12 from Alexander Monakov ---
For reference, the previous whacked mole appears to be PR 106187 (where
mems_same_for_tbaa_p comes from).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #8 from Alexander Monakov ---
Just optimizing out the redundant store seems difficult because on some targets
scheduling is invoked from reorg (and it relies on alias sets).
We need a solution that works for combine too — is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following testcase
#include
__attribute__((target("avx")))
int f(__m128i a[], long n)
{
for (long i = 0; i < n; i++)
if (!_mm_testz_si128(a[i], a[i]))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #19 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #18)
> True - but does that catch the cases people are interested and are
> allowed by the FP contraction rules? I'm thinking of
>
> x = a*b + c*d + e +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #17 from Alexander Monakov ---
(In reply to Richard Biener from comment #16)
> I do think that since the only way to
> preserve expression boundaries is by PAREN_EXPR
Yes, but...
> that the middle-end
> shouldn't care about FAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #15 from Alexander Monakov ---
(In reply to Richard Biener from comment #14)
> I can't
> seem to reproduce any vectorization for your smaller example though.
My small C samples omit some detail as they were meant to illustrate what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #7 from Alexander Monakov ---
I wanted to understand what gets exposed in LTO mode that causes a blowup.
I'd say flatten is not appropriate for this function (I don't think you want to
force inlining of memset or _find_next_bit?),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #5 from Alexander Monakov ---
(In reply to Jiri Slaby from comment #4)
> > I am surprised that "flatten" blows up on this function. Is that with any
> > config, or again some specific settings like gcov? Is there an existing lkml
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #13 from Alexander Monakov ---
(In reply to Richard Biener from comment #12)
> > Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> > rule?
>
> You mean in the frontend only for -ffp-contract=on?
Yes.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #11 from Alexander Monakov ---
Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
-ffp-contract=on/off?
Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
rule?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #7 from Alexander Monakov ---
Lawrence, thank you for the nice work reducing the testcase. For RawTherapee
the recommended course of action would be to compile everything with
-ffp-contract=off, then manually reintroduce use of fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
Summary|LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #10 from Alexander Monakov ---
Okay, so this should have been reported against Binutils, but since we are
having the conversation here: the current behavior is not good, gas is silently
selecting a different relocation kind for no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #8 from Alexander Monakov ---
Right, sorry, due to presence of 'main' I overlooked -fPIC in comment #0, and
then after my prompt it got dropped in comment #3.
If you modify the testcase as follows and compile it with -fPIC, it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #6 from Alexander Monakov ---
(In reply to Martin Liška from comment #5)
> Do you mean gas or ld?
gas
> How did you get this output, please (from foo.o or final executable)?
>From foo.o like in comment #0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #3 from Alexander Monakov ---
It would be unfortunate if that makes it difficult or even impossible to make a
R_386_32 relocation for the address of GOT in hand-written assembly.
In any case, it seems GCC is not making the rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Alexander Monakov changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
--- Comment #5 from Alexander Monakov ---
GCC discovers that 'bar' is noreturn, tries to remove its LHS but unfortunately
cgraph.cc:cgraph_edge::redirect_call_stmt_to_callee wants to emit an assignment
of SSA default-def to the LHS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
--- Comment #4 from Alexander Monakov ---
(In reply to Martin Liška from comment #3)
> > Also ICEs in ipa-modref when 'noclone' added to 'noinline', a 12/13
> > regression (different cause, needs a separate PR).
>
> Can't reproduce Alexander,
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following testcase, gcc -O2
unsigned foo(const unsigned char *buf, long size);
unsigned bar(const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #8 from Alexander Monakov ---
But that's the point of many warnings, isn't it? To help the user understand
what's wrong when the code is bad? And bogus warnings just confuse more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
201 - 300 of 1134 matches
Mail list logo