https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #12 from Mikael Morin ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Richard Biener from comment #10)
>
> > Is there any case where the frontend would make 'data' point into the
> > middle of the array and iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #14 from Mikael Morin ---
Created attachment 51787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51787&action=edit
draft patch
This "fixes" the problem of negative index access, and adjusts vector subscript
handling, so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51787|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #19 from Mikael Morin ---
(In reply to Thomas Koenig from comment #15)
> One possibility would be to extend the patch Sandra posted at
> https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html
> to scalarization.
Probably nic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #23 from Mikael Morin ---
(In reply to Richard Biener from comment #21)
> (In reply to Bernhard Reutner-Fischer from comment #17)
> > Do we want to address arrays always at position 0 (maybe to help graphite ?)
>
> Helping graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51839|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51891|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #28 from Mikael Morin ---
I’m reading the previous comments again:
(In reply to Richard Biener from comment #10)
> So to clarify the ARRAY_REF constraints - there is currently no way to
> construct a valid ARRAY_REF where an index d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
This has been identified in PR102043 comment #13.
Testcase from there:
program main
implicit none
integer, dimension :: a(4, 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671
Mikael Morin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #30 from Mikael Morin ---
*** Bug 103671 has been marked as a duplicate of this bug. ***
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
program p
integer :: z(2), y(2)
y = [1, 13]
z = maskl(y, kind=4) + 1
end
test.f90:4:27:
4 |z = maskl(y, kind=4) + 1
| 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789
--- Comment #1 from Mikael Morin ---
maskr is the same.
Fix probably similar to PR87851.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #5)
> (In reply to Mikael Morin from comment #4)
> > But is it required to generate a temporary?
> > As I understand it, the code is invalid, and (correctly) diagnosed, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #3)
> Could need help by some expert on this...
I guess I qualify as expert.
Reading the code again after years, it is not exactly crystal clear...
Here is a dump of what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #7)
>
> In the meantime, do you have an idea where to force the generation of a
> temporary? I've been scrolling through gfc_conv_procedure_call to see
> if that might be th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #12 from Mikael Morin ---
(In reply to anlauf from comment #11)
> Update: Steve Lionel thinks that no temporary is necessary, and testcase
> z1.f90
> is non-conforming:
>
> https://community.intel.com/t5/Intel-Fortran-Compiler/ELEME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
Testcase as reported by Harald here:
https://gcc.gnu.org/pipermail/fortran/2022-May/057841.html
su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #1 from Mikael Morin ---
In parse.cc, we avoid emitting an error if an other has been emitted.
But it uses the total error count, not the number of errors since we started
matching the current statement.
597 if (!gfc_error_check ()
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #11 from Mikael Morin ---
Patches posted:
v1:
https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html
v2:
https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html
11 backport:
https://gcc.gnu.org/pipermail/fortran/2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #6 from Mikael Morin ---
(In reply to kargl from comment #5)
> (In reply to Mikael Morin from comment #4)
>
> > (In reply to kargl from comment #3)
> > > Yep, agreed. I went back an re-read the section about ASSOCIATE.
> > > Not su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #6 from Mikael Morin ---
Created attachment 57571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571&action=edit
Tentative patch
(In reply to anlauf from comment #5)
> (In reply to anlauf from comment #4)
> > Thus I suggest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> I need to reevaluate it; there were other regressions if I remember
> correctly.
The changes are these:
PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #8)
> (In reply to Mikael Morin from comment #7)
> > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> > Excess errors:
> > /home/mik/gcc/gccx/src/gcc/testsuite/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #2 from Mikael Morin ---
Created attachment 57739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739&action=edit
Patch fixing the problem
This small patch fixes the problem.
Unfortunately allowing more errors seems counter-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472
Mikael Morin changed:
What|Removed |Added
Known to work||14.0
Known to fail|
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #3 from Mikael Morin ---
(In reply to anlauf from comment #2)
> (In reply to Jürgen Reuter from comment #1)
> > I suspect this commit here,
> > https://gcc.gnu.org/git/?p=gcc.git;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Mikael Mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #17 from Mikael Morin ---
Created attachment 55660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55660&action=edit
Update function type patch
This patch changes the dummy argument declaration type.
It changes the dump as foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #18 from Mikael Morin ---
Created attachment 55662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55662&action=edit
Updated tentative patch
This fixes comment #4 as well, but the failure on value_9 remains on 32 bit
powerpc.
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #19 from Mikael Morin ---
Patch submitted:
https://gcc.gnu.org/pipermail/fortran/2023-August/059666.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626870.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #40 from Mikael Morin ---
Harald, I have just closed the followup PR110419.
I think this PR can be closed as well, or is there something left to be done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something left
|NEW
Last reconfirmed||2023-08-17
CC||mikael at gcc dot gnu.org
--- Comment #5 from Mikael Morin ---
Confirmed on the reduced example from comment #2.
The problem arises because of the bogus subroutine statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #6 from Mikael Morin ---
(In reply to Mikael Morin from comment #5)
> Here sym->formal_ns is NULL because the symbol C has not been completely
> setup.
This makes the following an "obvious" fix:
diff --git a/gcc/fortran/decl.cc b/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #8 from Mikael Morin ---
(In reply to JuzheZhong from comment #7)
> Do you have a solution that we can fix RISC-V backend?
No, this is not RISC-V specific.
> Or you will fix it in Fortran front-end?
Yes, the fix will have to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).
Sorry, missed the -std=f95 flag.
Confirmed on recent master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
||mikael at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Mikael Morin ---
All the testcases here have been fixed by the fix for pr48776.
Closing as duplicate.
*** This bug has been marked as a duplicate of bug 48776 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #10 from Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
Bug 89891 depends on bug 48776, which changed state.
Bug 48776 Summary: ICE(segfault) after -std=f95 diagnostic error involving
PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
What|Removed |Added
-
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Mikael Morin ---
(In reply to anlauf from comment #4)
> Mikael,
>
> are you still onto it?
Thank
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
CC: anlauf at gcc dot gnu.org, dfranke at gcc dot gnu.org,
gcc-bugs at gcc dot gnu.org,
P.Schaffnit at access dot rwth-aachen.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #8 from Mikael Morin ---
Created attachment 56091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56091&action=edit
Rough patch
Here is a rough patch to make the scalarizer support minloc calls.
It regresses on minloc_1.f90 at l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #23 from Mikael Morin ---
(In reply to Mikael Morin from comment #21)
>
> (...) and should be able to submit the first
> series (inline minloc without dim argument) this week.
>
I missed the "this week" mark (again), but I've finall
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
The following example outputs:
1 1 2 3 5
while I think it should output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116196
--- Comment #1 from Mikael Morin ---
Draft patch:
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 15edf1af9df..348fd562ef6 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1253,11 +1253,8 @@ ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
Consider this:
program p
contains
subroutine s
contains
subroutine x
end subroutine x
end subroutine s
end program
It is rejected, but I couldn't find what i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116196
--- Comment #2 from Mikael Morin ---
More complete testcase:
! { dg-do run }
! { dg-additional-options "-fdump-tree-original" }
!
! PR fortran/116196
MODULE m
IMPLICIT NONE
INTEGER, TARGET :: arr(5)
END MODULE m
PROGRAM main
USE m
IMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116196
--- Comment #3 from Mikael Morin ---
Created attachment 58971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58971&action=edit
Draft patch
This fixes the testcase.
But the testcase is by far insufficient to thoroughly check the correctnes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116359
Mikael Morin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109626
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff --g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #3 from Mikael Morin ---
I'm working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #10 from Mikael Morin ---
(In reply to Mikael Morin from comment #8)
> (...) that is it was using too loops in a row in some cases.
>
... *two* loops in a row ...
(In reply to Tamar Christina from comment #9)
>
> Thanks Mikael!
>
|NEW
Keywords||patch
CC||mikael at gcc dot gnu.org
Last reconfirmed||2023-10-12
--- Comment #1 from Mikael Morin ---
Confirmed.
This should fix it:
diff --git a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56091|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #13 from Mikael Morin ---
(In reply to Tamar Christina from comment #12)
> (In reply to Mikael Morin from comment #11)
> > Created attachment 56094 [details]
> > Improved patch
> >
> > This improved patch (still single argument only)
at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #2 from Mikael Morin ---
I'm on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #3 from Mikael Morin ---
I'm trying to remove the formal_arg_flag global variables, which seem to just
disable all the checks on dummy arguments.
Unfortunately, it regresses a bit, say pr101026.f for example can be simplified
to thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56094|0 |1
is obsolete|
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
In the following example, I expect the ubound to be (/ 3, 0, 7 /), but the
printed values are (/ 0, 0, 7 /).
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #1 from Mikael Morin ---
(In reply to Mikael Morin from comment #0)
> i = 1
> (...)
> r = sum(a, dim=i)
If i is inlined, that is
r = sum(a, dim=1)
the shape and ubound are (/ 3, 0, 7 /) as expected.
The difference is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #2 from Mikael Morin ---
If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected.
That is, the problem only arises if the resulting array is empty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #3 from Mikael Morin ---
Possible culprit:
ifunction.m4 has this code:
retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
if (alloc_size == 0)
{
/* Make sure we have a zero-sized arra
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
Non-masked reduction functions work, but their masked variant don't allocate if
the result is empty, so the r
801 - 900 of 1007 matches
Mail list logo
