On Mon, Dec 6, 2021 at 4:45 PM Jan Hubicka wrote:
>
> > On Mon, Dec 6, 2021 at 4:03 PM Richard Biener
> > wrote:
> > >
> > > On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
> > > wrote:
> > > >
> > > > Richard Biener writes:
> > > > > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via
On Tue, Dec 7, 2021 at 8:43 AM Richard Biener
wrote:
>
> On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
> >
> > While reading the hash_map code I noticed this inconsistency. Bootstrapped
> > and
> > regtested on x86_64. OK for trunk?
>
> I've inspected two users of said overload and they
On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote:
>
> While reading the hash_map code I noticed this inconsistency. Bootstrapped and
> regtested on x86_64. OK for trunk?
I've inspected two users of said overload and they return true. Did you look
at the rest? I assume that bootstrapping
On Tue, Dec 7, 2021 at 1:01 AM Sandra Loosemore wrote:
>
> The attached patch fixes an ICE in lto1 at lto-partition.c:215 that
> was reported by a customer. Unfortunately I have no test case for
> this; the customer's application is a big C++ shared library with lots
> of dependencies and
On Mon, Dec 6, 2021 at 7:39 PM Andrew MacLeod wrote:
>
> On 12/6/21 02:27, Richard Biener wrote:
> > On Fri, Dec 3, 2021 at 9:42 PM Andrew MacLeod via Gcc-patches
> > wrote:
> >> When a request is made for the range of an ssa_name at some location,
> >> the first thing we do is invoke
Hi Segher,
on 2021/12/6 下午9:06, Segher Boessenkool wrote:
> On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrote:
This patch is to fix the inconsistent behaviors for non-LTO mode
and LTO mode. As Martin pointed out, currently the function
rs6000_can_inline_p simply makes it
Hi,
For a function with optimize pragma, it's possible that the target
options change as optimization options change. Now we create one
optimization option node when parsing pragma optimize, but don't
create target option node for possible target option changes. It
makes later processing not
This patch adds combine splitter to transform vpcmpeqd/vpxor/vblendvps to
vblendvps for ~op0.
OK for trunk?
BRs,
Haochen
gcc/ChangeLog:
PR target/100738
* config/i386/sse.md
(*_blendv_not_ltint):
Add new define_insn_and_split.
gcc/testsuite/ChangeLog:
PR
Hi!
On Mon, Dec 06, 2021 at 02:49:03PM -0600, Bill Schmidt wrote:
> To allow for a sane switch-over from the old built-in infrastructure to the
> new, both sets of code have co-existed, with the enabled one under the control
> of the boolean variable new_builtins_are_live. As a first step in
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
On 11/30/21 3:55 PM, Martin Sebor wrote:
Attached is a revision of this patch with adjustments for
the changes to the prerequisite patch 1 in the series and
a couple of minor simplifications and slightly improved
test
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585816.html
On 11/30/21 3:32 PM, Martin Sebor wrote:
Attached is a revised patch with the following changes based
on your comments:
1) Set and use statement uids to determine which statement
precedes which in the same basic
The attached patch fixes an ICE in lto1 at lto-partition.c:215 that
was reported by a customer. Unfortunately I have no test case for
this; the customer's application is a big C++ shared library with lots
of dependencies and proprietary code under NDA. I did try reducing it
with cvise but
Whilst debugging state explosions seen when enabling taint detection
with -fanalyzer (PR analyzer/103533), I noticed that constraint
manager instances could contain stray, redundant constants, such
as this instance:
constraint_manager:
equiv classes:
ec0: {(int)0 == [m_constant]‘0’}
Dear all,
using a bad expression as stride in a subsequent array section did
lead to an internal error which was directly invoked after the
failure. We better return a failure code to let error recovery
do its expected job.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Committed as trivial and obvious.
Fixes 85289ba36c2e62de84cc0232c954d9a74bda708a.
2021-12-06 Paul A. Clarke
gcc
PR target/103545
* config/rs6000/xmmintrin.h (_mm_movemask_ps): Replace "vector" with
"__vector".
---
gcc/config/rs6000/xmmintrin.h | 2 +-
1 file changed,
Dear all,
we didn't check the type of the upper bound in a case range.
Bummer. Simply add a corresponding check.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b4e7aeae4f6c59d8fe950d7981832e3f9c6a8f0e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 Dec 2021
MAINTAINERS: Add myself to write after approval and DCO sections.
* MAINTAINERS: Adding myself.
Best wishes,
Navid.
0001-MAINTAINERS-Add-myself-to-write-after-approval-and-D.patch
Description: 0001-MAINTAINERS-Add-myself-to-write-after-approval-and-D.patch
On 12/6/21 1:14 PM, Jeff Law wrote:
On 12/6/2021 10:31 AM, Martin Sebor wrote:
I have broken up the patch into a series of six. Attached is
part (1), the fix for the typo that causes PR 103143.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
On 12/3/21 19:44, Marek Polacek wrote:
On Thu, Dec 02, 2021 at 12:56:38PM -0500, Jason Merrill wrote:
On 12/2/21 10:27, Marek Polacek wrote:
On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
On 12/1/21 10:16, Marek Polacek wrote:
In C++23, auto(x) is valid, so decltype(auto(x))
On 12/4/21 15:26, Marek Polacek wrote:
Here, decltype deduces the wrong type for certain expressions involving
bit-fields. Unlike in C, in C++ bit-field width is explicitly not part
of the type, so I think decltype should never deduce to 'int:N'. The
problem isn't that we're not calling
Hi Marc, thanks for clear explanation.
Actually I have to withdraw this patch. As you noticed there are some problems
with this. I was testing it yesterday, and I did realize I made mistake
combining different types in this pattern.
The same approach would work only and only if the types of
This patch does a little bit of cleanup by removing some unused
arguments, or marking them as unused. It also removes the function
ctfc_debuginfo_early_finish_p and the corresponding hook macro
definition, which are not used by GCC.
gcc/
* config/bpf/bpf.c
Hi!
While we had two sets of built-in infrastructure at once, I added _x as a
suffix to two arrays to disambiguate the old and new versions. Time to fix
that also.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-06 Bill
Hi!
While we had two sets of built-in functionality at the same time, I put "new"
in the names of quite a few functions. Time to undo that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
*
Hi!
The old rs6000-builtin.def file is no longer needed. Remove it and the code
that depends on it.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin.def: Delete.
Hi!
This patch just renames a file and updates the build machinery accordingly.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def: Rename to...
*
Hi!
Now that the new built-in function support is all upstream and enabled, it
seems safe and prudent to remove the old code to avoid confusion. I broke this
up to the extent possible, but a couple of patches are still pretty large.
David Edelsohn found that I had broken some C++ library
On 12/6/2021 10:31 AM, Martin Sebor wrote:
I have broken up the patch into a series of six. Attached is
part (1), the fix for the typo that causes PR 103143.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that
On Mon, Dec 06, 2021 at 11:12:00AM -0700, Martin Sebor wrote:
> On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
> >Approach 1: Custom Address Spaces
> >=
> >
> >GCC's C frontend supports target-specific address spaces; see:
> >
Hi,
here is a first stab at the library side of power-ieee128,
committed to the branch.
It compiles, but probably still has a lot of issues. It
is also not called from the compiler yet.
Regards
Thomas
2021-10-19 Thomas Koenig
Prepare library for REAL(KIND=17).
This
If one of the to-be-converted SETs requires the original comparison
(i.e. in order to generate a min/max insn) but no other insn after it
does, we can omit creating temporaries, thus facilitating costing.
---
gcc/ifcvt.c | 33 +++--
1 file changed, 31 insertions(+), 2
Add new s390-specific tests that check if we convert two SETs into two
loads on condition. Remove the s390-specific target-check in
gcc.dg/ifcvt-4.c.
---
gcc/testsuite/gcc.dg/ifcvt-4.c| 2 +-
.../gcc.target/s390/ifcvt-two-insns-bool.c| 39 +++
Following up on the previous patch, this patch makes
noce_convert_multiple emit two cmov sequences: The same one as before
and a second one that tries to re-use the existing CC. Then their costs
are compared and the cheaper one is selected.
---
gcc/ifcvt.c | 112
Currently we only ever call emit_conditional_move with the comparison
(as well as its comparands) we got from the jump. Thus, backends are
going to emit a CC comparison for every conditional move that is being
generated instead of re-using the existing CC.
This, combined with emitting temporaries
This lifts the restriction of not allowing constants for
noce_convert_multiple. The code later checks if a valid sequence
is produced anyway.
---
gcc/ifcvt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index c98668d5646..4642176957e
When noce_convert_multiple is called the original costs are not yet
initialized. Therefore, up to now, costs were only ever unfairly
compared against COSTS_N_INSNS (2). This would lead to
default_noce_conversion_profitable_p () rejecting all but the most
contrived of sequences.
This patch
When if-converting multiple SETs and we encounter a swap-style idiom
if (a > b)
{
tmp = c; // [1]
c = d;
d = tmp;
}
ifcvt should not generate a conditional move for the instruction at
[1].
In order to achieve that, this patch goes through all relevant SETs
and
Hi Richard,
as requested, this is the whole series (without the s390-specific parts)
in total. 7/7 is "new" as it was posted separately as "8/7" before
but actually does not change too much compared to the rest.
Supposing that the adjusted 4/7 is OK after recent discussions, if I'm
not
On 12/6/21 02:27, Richard Biener wrote:
On Fri, Dec 3, 2021 at 9:42 PM Andrew MacLeod via Gcc-patches
wrote:
When a request is made for the range of an ssa_name at some location,
the first thing we do is invoke range_of_stmt() to ensure we have looked
at the definition and have an evaluation
On 11/18/21 4:34 PM, David Malcolm via Gcc-patches wrote:
On Wed, 2021-11-17 at 22:43 +, Joseph Myers wrote:
On Wed, 17 Nov 2021, Prathamesh Kulkarni via Gcc-patches wrote:
More generally, would it be a good idea to provide attributes for
mod/ref anaylsis ?
So sth like:
void foo(void)
On 11/13/21 1:37 PM, David Malcolm via Gcc-patches wrote:
[Crossposting between gcc-patches@gcc.gnu.org and
linux-toolcha...@vger.kernel.org; sorry about my lack of kernel
knowledge, in case of the following seems bogus]
I've been trying to turn my prototype from the LPC2021 session on
"Adding
Attached is the subset of the patch in part (5) below: Add
a new dump function. It applies on top of patch 4/5.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by most
Attached is the subset of the patch in part (2) below: refactor
compute_objsize_r into helpers. It applies on top of patch 3/5.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in
Attached is subset of the patch in part (4) below: factor out
PHI handling. It applies on top of patch 3/5.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by most
Attached is the subset of the patch in part (3) below: Pass
GIMPLE statement to compute_objsize. It applies on top of
patch 1/5.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in
Attached is the subset of the patch in part (1) below: Move
bndrng from access_ref to access_data.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by most middle end
I have broken up the patch into a series of six. Attached is
part (1), the fix for the typo that causes PR 103143.
On 12/3/21 5:00 PM, Jeff Law wrote:
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by
I had difficulty with patch 1/6 being too large, and there have been some small
upstream changes in this area, so I will resubmit this series shortly. There
were also problems with my SMTP server for some of the CCs as well...
Sorry for the churn!
Bill
On 12/3/21 12:22 PM, Bill Schmidt wrote:
>
Hi everyone,
Since support for target aarch64-apple-darwin has been submitted for review,
it’s time to submit the Fortran part, i.e. enabling IEEE support on that target.
The patch has been in use now for several months, in a developer branch shipped
by some distros on macOS (including
On Mon, Dec 06, 2021 at 05:06:10PM +0100, Tobias Burnus wrote:
> Regarding the sorting and iterators: I think we already have this problem
> intrinsically – for depend/affinity, we create for (iterator(...) :
> a, b)
> a single loop - also to have a consistency with regards to the array bounds.
On 06.12.21 16:16, Jakub Jelinek wrote:
I think there is no reason why the 3 arrays passed to GOMP_target_ext
(etc., for target data {, enter, exit} too and because this
affects to and from clauses as well, target update as well)
need to be constant size.
We do a lot of sorting of the map
On Tue, Nov 30, 2021 at 06:20:09AM -0800, H.J. Lu via Gcc-patches wrote:
> Use SSE, instead of AVX, to save and restore XMM registers to support
> processors without AVX. The affected codes are unused in upstream since
>
> https://github.com/llvm/llvm-project/commit/66d4ce7e26a5
>
> and will be
> On Mon, Dec 6, 2021 at 4:03 PM Richard Biener
> wrote:
> >
> > On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
> > wrote:
> > >
> > > Richard Biener writes:
> > > > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches
> > > > wrote:
> > > >>
> > > >> When compiling an
Richard Biener writes:
> On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches
>> > wrote:
>> >>
>> >> When compiling an optabs.ii at -O2 with a release-checking build,
>> >> we spent a lot
On Mon, Dec 06, 2021 at 03:00:30PM +0100, Tobias Burnus wrote:
> This is a RFC/WIP patch about:
>
> (A) OpenMP (C/C++/Fortran)
>omp target map(iterator(i=n:m),to : x(i))
>
> (B) Fortran:
> (1) omp target map(to : dt_var, class_var)
> (2) omp parallel allocator(my_alloc)
The recent fix to PR103527 exposed an issue with how the various
special casing for AVX512 masks in vect_build_gather_load_calls
are handled. The following makes that more obvious, fixing the
miscompile of 403.gcc.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-12-06 Richard
On Mon, Dec 6, 2021 at 4:03 PM Richard Biener
wrote:
>
> On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches
> > > wrote:
> > >>
> > >> When compiling an optabs.ii at -O2 with a
On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> When compiling an optabs.ii at -O2 with a release-checking build,
> >> we spent a lot of time in call_may_clobber_ref_p.
First, thanks for the four reviews. Secondly, I missed one patch –
hence, reposted with all three pending patches:
* Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584894.html
and:
On 01.12.21 17:34, Tobias Burnus
On 12/6/21 7:06 AM, Segher Boessenkool wrote:
> On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrot
>> Without this fix, bar inlines foo but get the error as below:
>>
>> In function ‘foo’,
>> inlined from ‘bar’ at test.c:8:8:
>> test.c:3:9: error: ‘__builtin_ttest’ requires the ‘-mhtm’
Richard Earnshaw via Gcc-patches writes:
[...]
>> Thanks for the reviews.
>> Add -mbranch-protection option. This option enables the
>> code-generation of
>> pointer signing and authentication instructions in function prologues and
>> epilogues.
>> 2021-10-25 Tejas Belagod
>> gcc/ChangeLog:
On 12/6/21 3:35 AM, Martin Liška wrote:
> On 12/4/21 00:23, Peter Bergner wrote:
>> I thought Martin and richi mentioned that target attribute options
>> are treated as if they are appended to the end of the command line
>> options, so they can potentially override earlier options, but they
>>
This is a RFC/WIP patch about:
(A) OpenMP (C/C++/Fortran)
omp target map(iterator(i=n:m),to : x(i))
(B) Fortran:
(1) omp target map(to : dt_var, class_var)
(2) omp parallel allocator(my_alloc) firstprivate(class_var)
(3) call co_reduce(dt_coarray, my_func)
The problem with (A) is that
On 12/5/21 16:55, Richard Sandiford via Gcc-patches wrote:
This gives a ~2% compile-time speed up with the test above.
I also tried adding a path for two single-pair ranges, but it
wasn't a win.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
Thanks for these
On Fri, Dec 03, 2021 at 11:46:53AM +0800, Kewen.Lin wrote:
> >> This patch is to fix the inconsistent behaviors for non-LTO mode
> >> and LTO mode. As Martin pointed out, currently the function
> >> rs6000_can_inline_p simply makes it inlinable if callee_tree is
> >> NULL, but it's wrong, we
On 12/6/21 13:03, Martin Liška wrote:
gcc/d/expr.cc:2596:9: runtime error: null pointer passed as argument 2, which
is declared to never be null
I forgot to mention that it happens for gcc/testsuite/gdc.dg/attr_optimize1.d
test-case.
Cheers,
Martin
Fixes:
gcc/d/expr.cc:2596:9: runtime error: null pointer passed as argument 2, which
is declared to never be null
Ready for master?
Thanks,
Martin
gcc/d/ChangeLog:
* expr.cc: Call memcpy only when length != 0.
---
gcc/d/expr.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
When SLP reduction chain vectorization support added handling of
an outer conversion in the chain picking a failed reduction up
as SLP reduction that broke the invariant that the whole reduction
was forward reachable. The following plugs that hole noting
a future enhancement possibility.
On 12/6/21 11:23, Jakub Jelinek wrote:
|This patch fixes that.|
Thanks for the quick fix!
Martin
Richard Earnshaw writes:
> On 30/11/2021 11:11, Andrea Corallo via Gcc-patches wrote:
>> Tejas Belagod via Gcc-patches writes:
>>
>>> Ping for this series.
>>>
>>> Thanks,
>>> Tejas.
>> Hi all,
>> pinging this series.
>> BR
>>Andrea
>>
Hi Richard,
thanks for reviewing.
> It would be
While reading the hash_map code I noticed this inconsistency. Bootstrapped and
regtested on x86_64. OK for trunk?
The hash_map::traverse overload taking a non-const Value pointer breaks
if the callback returns false. The other overload should behave the
same.
Signed-off-by: Matthias Kretz
Hi!
On Mon, Dec 06, 2021 at 11:00:30AM +0100, Martin Liška wrote:
> Jakub, I think the patch broke avr-linux target:
>
> g++ -fno-PIE -c -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual
Tamar Christina writes:
> Hi,
>
> As discussed off-line this can only happen with a V1 mode, so here's a much
> simpler patch.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu,
> x86_64-pc-linux-gnu and no regressions.
>
>
> Ok for master?
OK, thanks.
Richard
> Thanks,
> Tamar
>
>
On 11/18/21 09:04, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 08, 2021 at 08:48:07PM +0100, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 08, 2021 at 12:46:04PM +0100, Jakub Jelinek via Gcc-patches wrote:
So, if we want to make PCH work for PIEs, I'd say we can:
1) add a new GTY
Hi,
As discussed off-line this can only happen with a V1 mode, so here's a much
simpler patch.
Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR rtl-optimization/103404
* cse.c
On 12/4/21 00:23, Peter Bergner wrote:
On 12/2/21 9:46 PM, Kewen.Lin via Gcc-patches wrote:
on 2021/11/30 上午12:57, Segher Boessenkool wrote:
On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
This patch is to fix the inconsistent behaviors for non-LTO mode
and LTO mode. As Martin
Committed, thanks :)
On Mon, Nov 29, 2021 at 8:48 PM Nelson Chu wrote:
>
> This is the original binutils bugzilla report,
> https://sourceware.org/bugzilla/show_bug.cgi?id=28509
>
> And this is the first version of the proposed binutils patch,
>
On Mon, Dec 6, 2021 at 4:41 AM liuhongt via Gcc-patches
wrote:
>
> When moves between integer and sse registers are cheap.
>
> 2021-12-06 Hongtao Liu
> Uroš Bizjak
> gcc/ChangeLog:
>
> PR target/95740
> * config/i386/i386.c (ix86_preferred_reload_class): Allow
>
On Sun, Dec 5, 2021 at 11:02 PM Richard Sandiford via Gcc-patches
wrote:
>
> In self-compilations, GCC doesn't realise that gimple_seq_last
> always returns nonnull when the argument is nonnull. Although
> it's a small thing in itself, the function is used (indirectly)
> many times and the extra
79 matches
Mail list logo
