https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92553
--- Comment #2 from Ye Luo ---
PR92357 mentioned that you backported a fix to the gcc 9 branch and how I'm
getting the following error
/home/yeluo/opt/gcc-9-branch/bin/g++ -fopenmp -foffload=nvptx-none
-foffload=-lm -fomit-frame-pointer
Iain Sandoe writes:
> Ian Lance Taylor wrote:
>
>> Iain Sandoe writes:
>
>>> 2020-01-09 Iain Sandoe
>>>
>>> * cp-demangle.c (cplus_demangle_operators): Add the co_await
>>> operator.
>>
>> Please add something to libiberty/testsuite/demangle-expected. Thanks.
>
> done***,
> OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #4 from Andrew Pinski ---
>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 means VDSO functions are not the same ABI as normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92941
--- Comment #1 from Andrew Pinski ---
The reason why this has not been seen as much as building without the C++
front-end is not something 99% people do, even cross compiler folks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135
Andrew Pinski changed:
What|Removed |Added
Depends on||93221
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
--- Comment #3 from Andrew Pinski ---
aarch64 is one of the few targets that has a floating point type which is less
than SImode :).
A simple workaround for this bug is to change the code slightly:
struct sfp16 {
__fp16 f;
};
struct sfp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
--- Comment #1 from Andrew Pinski ---
*** Bug 93236 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
--- Comment #1 from Jim Rees ---
Created attachment 47639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47639=edit
sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
Bug ID: 93236
Summary: [AArch64] ICE
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Bug ID: 93235
Summary: [AArch64] ICE
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #4 from Andrew Pinski ---
Note the patch also does not handle the following (or something a little more
complex):
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
#define vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Richard Biener from comment #2)
> > OK for trunk.
>
> Except it is wrong if the size(@1) != size(@3). I Noticed that after I
> created this bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> It's a bugfix so applicable for stage3... pre-approved with a testcase.
Except it causes a regression on x86_64:
FAIL: gcc.target/i386/pr54855-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> Indeed that seems to disallow this case. The condition is complicated
> enough to warrant extra care fiddling with it though ;)
The main reason why I filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> OK for trunk.
Except it is wrong if the size(@1) != size(@3). I Noticed that after I created
this bug report. I have a better fix; though I combined it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
--- Comment #3 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #2)
> Is that a method to dump the entire processed source?
Please read https://gcc.gnu.org/bugs/ under the "Detailed bug reporting
instructions" section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318
--- Comment #5 from Piotr Henryk Dabrowski ---
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234
Bug ID: 93234
Summary: INQUIRE on pre-assigned files of ROUND and SIGN
properties fails
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
On Sat, 11 Jan 2020, Joseph Myers wrote:
> the older test conversions 1 through 7). Some cron jobs may be re-enabled
> before then, subject to testing (I have git changes to gcc_release ready,
> for example, for testing snapshot generation), but the DATESTAMP updates
> won't be enabled until
Snapshot gcc-9-20200111 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200111/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
From: Andrew Pinski
Like I mentioned in https://gcc.gnu.org/ml/gcc/2020-01/msg00157.html,
The shift by a register should be just COSTS_N_INSNS (1) rather than
COSTS_N_INSNS (2). This allows lshift_cheap_p to return true now
and converting switches to be using shift and other like
structures. I
From: Andrew Pinski
This adds octeontx2 naming. It currently uses the cortexa57
cost model and schedule model until I submit this. This is
more a place holder to get the naming of the cores in GCC 10.
I will submit the cost model in the next couple of days.
OK? Bootstrapped and tested on
Le 11/01/2020 à 14:49, Jakub Jelinek a écrit :
On Sat, Jan 11, 2020 at 07:43:17AM -0600, Segher Boessenkool wrote:
On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote:
Maybe even add https://gcc.gnu.org/gNNN for 7-40 hexadecimal digits
redirect to
Hi!
On Fri, Jan 10, 2020 at 10:35:04PM +0100, Jakub Jelinek wrote:
> On Thu, Jan 09, 2020 at 02:26:10PM +0100, Richard Biener wrote:
> > > >> + tree lhs = gimple_assign_lhs (stmt);
> > > >> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type),
> > > >> val);
> > > >
> > > >
On Sat, 11 Jan 2020, Thomas Koenig wrote:
> Hm... I just hope this is a one-time effect, and isn't an indication
> that git uses much more resources, server-side, so the current
> infrastructure is not up to the task. Is git that much more
> resource hungry than svn? Or is this unrelated?
I
Thomas Koenig :
> Hm... I just hope this is a one-time effect, and isn't an indication
> that git uses much more resources, server-side, so the current
> infrastructure is not up to the task. Is git that much more
> resource hungry than svn? Or is this unrelated?
Almost certanly unrelated. In
Hi Martin,
It does not for me
(something about public key rejected), but then I am a complete novice
at using git, so I am more or less doing vodoo git here.
Please paste the error message you face?
Currently, gcc.gnu.org is totally under water, even accessing the
wiki leads to a timeout,
On Sat, 11 Jan 2020, Thomas Koenig wrote:
> Am 11.01.20 um 15:39 schrieb Joseph Myers:
> > This conversion is now in place, read-only for checking purposes. I've
> > done all the usual validation, including in particular checking branch
> > tips and tags against SVN.
>
> Is checkout via git+ssh
On 1/11/20 5:33 PM, Thomas Koenig wrote:
Am 11.01.20 um 15:39 schrieb Joseph Myers:
This conversion is now in place, read-only for checking purposes. I've
done all the usual validation, including in particular checking branch
tips and tags against SVN.
Is checkout via git+ssh supposed to
On Jan 11 2020, Jakub Jelinek wrote:
> g:releases/gcc-9@{yesterday} references (and, there we at least shouldn't
@{yesterday} operates on reflogs, a local concept that is useless
outside your own repository.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47
On Jan 11 2020, Richard Earnshaw wrote:
> $ git ls-remote|grep vendors|sed -r "s|.*vendors/([^/]+).*|\1|"|sort|uniq
git ls-remote URL "*/vendors/*" | ...
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for
On 11/01/2020 16:33, Thomas Koenig wrote:
> Am 11.01.20 um 15:39 schrieb Joseph Myers:
>> This conversion is now in place, read-only for checking purposes. I've
>> done all the usual validation, including in particular checking branch
>> tips and tags against SVN.
>
> Is checkout via git+ssh
On Jan 11 2020, Richard Earnshaw wrote:
> Once you have a checkout, "git ls-remote" will show all the refs on the
> server.
You don't need a checkout, git ls-remote works on a remote URL.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552
On Sat, Jan 11, 2020 at 05:24:19PM +0100, Andreas Schwab wrote:
> ../../gcc/tree-ssa-forwprop.c: In function 'bool
> simplify_count_trailing_zeroes(gimple_stmt_iterator*)':
> ../../gcc/tree-ssa-forwprop.c:1925:23: error: variable 'mode' set but not
> used [-Werror=unused-but-set-variable]
>
Am 11.01.20 um 15:39 schrieb Joseph Myers:
This conversion is now in place, read-only for checking purposes. I've
done all the usual validation, including in particular checking branch
tips and tags against SVN.
Is checkout via git+ssh supposed to work for this? It does not for me
(something
On Sat, Jan 11, 2020 at 12:28:01PM +0100, Jakub Jelinek wrote:
> For the redirectors, it could be something like following patch, except the
> last new redirect would need also a yet to be written cgi script that would
> git undescr the argument and print
> Location:
../../gcc/tree-ssa-forwprop.c: In function 'bool
simplify_count_trailing_zeroes(gimple_stmt_iterator*)':
../../gcc/tree-ssa-forwprop.c:1925:23: error: variable 'mode' set but not used
[-Werror=unused-but-set-variable]
1925 | scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
|
On 11/01/2020 15:41, Segher Boessenkool wrote:
> Hi Richard,
>
> On Thu, Jan 09, 2020 at 04:50:03PM +, Richard Earnshaw (lists) wrote:
>> Given the proposed intention to use non-standard refspecs for private
>> and vendor branches I've written some notes on how to use these.
>>
>> It would
On Sat, 11 Jan 2020, Richard Earnshaw wrote:
> On 11/01/2020 14:58, Jakub Jelinek wrote:
> > On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote:
> >> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch
> >>
> >> Works
> >>
> >> Or for tags
Hi Richard,
On Thu, Jan 09, 2020 at 04:50:03PM +, Richard Earnshaw (lists) wrote:
> Given the proposed intention to use non-standard refspecs for private
> and vendor branches I've written some notes on how to use these.
>
> It would be helpful if someone could do some experiments to ensure
On 11/01/2020 15:01, Richard Earnshaw wrote:
> On 11/01/2020 14:58, Jakub Jelinek wrote:
>> On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote:
>>> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch
>>>
>>> Works
>>>
>>> Or for tags s/heads/tags/
On 11/01/2020 14:58, Jakub Jelinek wrote:
> On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote:
>> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch
>>
>> Works
>>
>> Or for tags s/heads/tags/
>
> Indeed, this works, but if one doesn't know what
On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch
>
> Works
>
> Or for tags s/heads/tags/
Indeed, this works, but if one doesn't know what branches there are for
particular vendor or what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 11/01/2020 14:51, Richard Earnshaw wrote:
> On 11/01/2020 14:49, Richard Earnshaw wrote:
>> On 11/01/2020 14:48, Jakub Jelinek wrote:
>>> On Sat, Jan 11, 2020 at 02:39:43PM +, Joseph Myers wrote:
> On 11/01/2020 01:18, Joseph Myers wrote:
>> The GCC SVN repository is now read-only
On 11/01/2020 14:49, Richard Earnshaw wrote:
> On 11/01/2020 14:48, Jakub Jelinek wrote:
>> On Sat, Jan 11, 2020 at 02:39:43PM +, Joseph Myers wrote:
On 11/01/2020 01:18, Joseph Myers wrote:
> The GCC SVN repository is now read-only for the move to git, as is the
> old
>
On 11/01/2020 14:48, Jakub Jelinek wrote:
> On Sat, Jan 11, 2020 at 02:39:43PM +, Joseph Myers wrote:
>>> On 11/01/2020 01:18, Joseph Myers wrote:
The GCC SVN repository is now read-only for the move to git, as is the old
git-svn mirror; the cron job updating that mirror has been
On Sat, Jan 11, 2020 at 02:39:43PM +, Joseph Myers wrote:
> > On 11/01/2020 01:18, Joseph Myers wrote:
> > > The GCC SVN repository is now read-only for the move to git, as is the
> > > old
> > > git-svn mirror; the cron job updating that mirror has been disabled, as
> > > have gccadmin's
On Sat, 11 Jan 2020, Richard Earnshaw wrote:
> On 11/01/2020 01:18, Joseph Myers wrote:
> > The GCC SVN repository is now read-only for the move to git, as is the old
> > git-svn mirror; the cron job updating that mirror has been disabled, as
> > have gccadmin's cron jobs updating DATESTAMP,
On Sat, Jan 11, 2020 at 09:15:11AM -0500, Jason Merrill wrote:
> > On Fri, Jan 10, 2020 at 10:47:47PM +0100, Jakub Jelinek wrote:
> > > Ah, you suggested g: rather than just g.
> > > We could then support
> > > rN (1-6 decimal digits) - the svn revs, either for old repo, or
> > transformed
> >
On Sat, Jan 11, 2020 at 6:28 AM Jakub Jelinek wrote:
> On Fri, Jan 10, 2020 at 10:47:47PM +0100, Jakub Jelinek wrote:
> > Ah, you suggested g: rather than just g.
> > We could then support
> > rN (1-6 decimal digits) - the svn revs, either for old repo, or
> transformed
> > g:X (X is any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source?
>
> This might be a dup of bug 92955.
The source is here:
On Sat, Jan 11, 2020 at 07:43:17AM -0600, Segher Boessenkool wrote:
> On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote:
> > Maybe even add https://gcc.gnu.org/gNNN for 7-40 hexadecimal digits
> > redirect to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=NNN
> > and then just
On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote:
> Maybe even add https://gcc.gnu.org/gNNN for 7-40 hexadecimal digits
> redirect to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=NNN
> and then just put as URL those
>
On 11/01/2020 01:18, Joseph Myers wrote:
> The GCC SVN repository is now read-only for the move to git, as is the old
> git-svn mirror; the cron job updating that mirror has been disabled, as
> have gccadmin's cron jobs updating DATESTAMP, generating snapshots and
> updating online
On 11/01/20 6:55 pm, Segher Boessenkool wrote:
> -ffreestanding means you might not have any of the C standard library,
> and -nostartfiles means you do not do any of the standard initialisation.
> Why then would you expect any ifunc to work?
>
Agreed, based on Alexander's feedback I have
Ian Lance Taylor wrote:
> Iain Sandoe writes:
>> 2020-01-09 Iain Sandoe
>>
>> * cp-demangle.c (cplus_demangle_operators): Add the co_await
>> operator.
>
> Please add something to libiberty/testsuite/demangle-expected. Thanks.
done***,
OK now?
thanks
Iain
*** it seems that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9
Hi!
On Fri, Jan 10, 2020 at 09:50:48PM +0530, Siddhesh Poyarekar wrote:
> Statically built independent programs that implement their own program
> entry points (i.e. -ffreestanding -nostartfiles) and call __builtin_*
> functions break when the builtin function in question is implemented as
> an
Already when we converted from CVS to SVN aeons ago did I work
to reduce references to a concrete system.
These are two further instances, now that we are moving to GIT.
Committed.
Gerald
- Log -
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
--- Comment #1 from Chris Sykes ---
I noticed that g++ also fails to warn about this with a similar test
case written in c++, and found this old bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Perhaps this is easier to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
Bug ID: 93233
Summary: No warning for possibly uninitialised return
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Hi Martin,
This change (r280099) is causing a major performance regression on exchange2 in
SPEC2017 dropping the benchmark by more than 30%.
It seems the parameters no longer do anything. i.e. -flto --param
ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 doesn't have any effect
anymore.
On Fri, Jan 10, 2020 at 12:38:10PM +0100, Richard Biener wrote:
> Just to chime in I also just want to get it done (well, I can handle
> SVN as well :P).
I will never have to learn it! I'm so happy!
> I trust Joseph, too, but then from my POV anything not worse than the current
> mirror works
On Fri, Jan 10, 2020 at 09:49:41AM +, Richard Earnshaw (lists) wrote:
> On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
> >>On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> >> wrote:
> >>Where and when and by who was it decided to use this conversion?
> >
> >Joseph, please point to message on gcc@
On Thu, Jan 09, 2020 at 12:12:49PM +, Richard Earnshaw (lists) wrote:
> On 09/01/2020 02:38, Segher Boessenkool wrote:
> >Where and when and by who was it decided to use this conversion?
> >
> >Will it at least be *tested* first?
>
> Tested for what?
Acceptance test, of course, the only test
On Fri, Jan 10, 2020 at 10:47:47PM +0100, Jakub Jelinek wrote:
> Ah, you suggested g: rather than just g.
> We could then support
> rN (1-6 decimal digits) - the svn revs, either for old repo, or
> transformed
> g:X (X is any [0-9a-zA-Z_-], something else?, 1 or more chars) - gitweb
>
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
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()
>
writes:
> From: Andrew Pinski
>
> This adds octeontx2 naming. It currently uses the cortexa57
> cost model and schedule model until I submit this. This is
> more a place holder to get the naming of the cores in GCC 10.
> I will submit the cost model in the next couple of days.
>
> OK?
On Sat, Jan 11, 2020 at 2:02 AM Andrew Pinski wrote:
>
> Hi,
> I was looking into reassoc (for PR 93131) and I noticed that the
> alu.shift_reg is set to COSTS_N_INSNS (1). This prevents an
> optimization where we combine some if statements into shifts. I
> looked into the Corext A57 software
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #6 from Andrew Pinski ---
(In reply to Roland Illig from comment #5)
> This is worse than before.
Not exactly because if write fails to stderr, there is not much to be done
except abort :). You can print something out because the
On Fri, Jan 10, 2020 at 07:50:02PM +0100, Jakub Jelinek wrote:
> The changes I was asking for is, for gcc master and releases/gcc-* branch
> commits to have the monotonically increasing short ids (printed by git descr
> with the git aliases I've posted) both somewhere early
> in the subject
Hi,
I was looking into reassoc (for PR 93131) and I noticed that the
alu.shift_reg is set to COSTS_N_INSNS (1). This prevents an
optimization where we combine some if statements into shifts. I
looked into the Corext A57 software optimization guide[1] and saw that
shift with a register has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #5 from Roland Illig ---
(In reply to Jakub Jelinek from comment #4)
> Change return type from void to int.
Not quite. The return type is now bool, not int.
> Return true if not all characters have been written.
This feels wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #5 from Mikael Pettersson ---
Confirmed, needs -msoft-float or selecting a CPU model which implies that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #19 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #17)
> Dunno about others, but this particular optimization could be done in a new
> function called next to optimize_range_tests_cmp_bitwise and
>
83 matches
Mail list logo
