Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat foo.f90
module foo_module
implicit none
interface
module function foo() result(bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #2 from Damian Rouson ---
Thanks for the quick reply, Steve. My apologies for not providing any text. I
dashed this off during a call with the person who reported the problem to me.
I think the code is legal, but I'm very open to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #6 from Damian Rouson ---
Thanks, Tobias!
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles cleanly with the NAG Fortran compiler. I believe the
error message is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #2 from Damian Rouson ---
Hi Dominique,
> What do you want to do with your test?
I don't understand the question. The submitted code is designed to be a minimal
demonstration of the problem so I don't want to do anything with it oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #7 from Damian Rouson ---
For context, I nearly always put the procedure definition in a submodule. In
this case, I'm attempting to use a tool that needs to parse the code and the
tool doesn't support submodules so I moved the proced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #9 from Damian Rouson ---
(In reply to Dominique d'Humieres from comment #3)
>
> Do you mean this is F2008 extension?
Usually I think of "extension" as describing something non-standard. This is a
standard feature. I meant simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #12 from Damian Rouson ---
Thanks to each of you for looking at and working on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #21 from Damian Rouson ---
Now that the patch fixing this PR has been committed to the trunk, should it be
marked as "Resolved" instead of "Assigned?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #23 from Damian Rouson ---
A related issue arises if the procedure in question is a pure function as
demonstrated below. The code compiles cleanly if either
1. The result-spec is absent and the procedure is renamed new_foo in both th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #24 from Damian Rouson ---
This appears to be another example of an issue with a module procedure defined
in the same module as its interface body. In this case, the compiler doesn't
recognize a reference to the procedure:
± cat subr
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below effectively has an abstract parent type ("object"), abstract
child type ("oracle")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #27 from Damian Rouson ---
Thanks, Paul! We'll test the patch.
Damian
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The ICE demonstrated below disappears if any one of the following is true:
1. The module and submodule are in the same file, or
2
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below generates an internal compiler error (ICE) in gfortran 8.3.0,
9.2.0, and in 10.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671
--- Comment #1 from Damian Rouson ---
The submitted code also compiles and executes cleanly with the NAG Fortran
compiler version 7.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #29 from Damian Rouson ---
Hi Paul,
The test case works with your patch applied. Thanks!
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82077
--- Comment #11 from Damian Rouson ---
Thanks, Paul!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
--- Comment #13 from Damian Rouson ---
Thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #5 from Damian Rouson ---
This is an exciting idea. When I gave some thought to writing a shared-memory
alternative coarray ABI, it seemed to me that pthreads would be a better choice
than OpenMP. Part of the problem is that I was c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #6 from Damian Rouson ---
Correction to the end of the first sentence of the final paragraph in Comment
5: "... not join them _until_ the end."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 84894, which changed state.
Bug 84894 Summary: [F2018] provide ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #8 from Damian Rouson ---
(In reply to Nicolas Koenig from comment #7)
> I actually opted to use multiprocessing with shared memory (shm_open() & co)
> instead of multithreading, since it will be much easier and faster with
> static
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$cat corrupted-component.f90
type foo
character(len=:), allocatable :: string
end type
type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
--- Comment #3 from Damian Rouson ---
I just created PR89200, on which this meta-bug should depend, but I don't know
how to edit the "Depends on" list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200
--- Comment #1 from Damian Rouson ---
gfortran 8.2.0 code gives the correct output:
$gfortran corrupted-component.f90
$./a.out
12
$gfortran --version
GNU Fortran (GCC) 8.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200
--- Comment #4 from Damian Rouson ---
Thanks, Paul!
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles without error with -fcoarray=single; whereas compiling
with -fcoarray=lib generates the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85510
--- Comment #1 from Damian Rouson ---
As similar error message results if the associate construct is replaced with a
block construct of the form
block
integer n
n=1
print*,i[1]
end block
The error disappears if the 'bl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82275
--- Comment #9 from Damian Rouson ---
Thanks, Paul!
Damian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
--- Comment #3 from Damian Rouson ---
Oxford University graduate student Daniel Celis Garza has been working on this
for the bulk of his 11-week visit with me, which ends next week. For reasons
motivated largely by the difficulty of coaxing the G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 84894, which changed state.
Bug 84894 Summary: [F2018] provide ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606
--- Comment #12 from Damian Rouson ---
Thank you, Andre!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894
--- Comment #6 from Damian Rouson ---
Sounds good. I agree that it would be great for gfortran to provide
ISO_Fortran_binding.h independently. Hopefully the OpenCoarrays version will be
a useful starting point. My understanding is that it's alway
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Based on a quick search, I don't think the Fortran standard uses the term
"impur
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$cat concat-deferred-len.f90
type core
character (len=:), allocatable :: msg
end type
type(core) :: my_core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91717
--- Comment #1 from Damian Rouson ---
FYI, this reproducer was developed by Paul Thomas based on my report that the
gfortran trunk is unable to build the json-fortran repository
(https://jacobwilliams.github.io/json-fortran/).
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Below is the trailing output of configuring MPICH 3.2, 3.2.1, or 3.3.1 with the
current GCC trunk:
configure: error: The Fortran compiler /opt/gnu/10.0.0/bin/gfortran will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #3 from Damian Rouson ---
So do I need to report this to the MPICH developers or is a gfortran bug? I
tried "-w -fallow-argument-mismatch" and got the same error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #5 from Damian Rouson ---
MPICH must find ISO_Fortran_binding.h in order to build the modern Fortran
bindings that the MPI standard provides through the "mpi_f08" Fortran module.
Gfortran only started providing ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731
--- Comment #6 from Damian Rouson ---
Steve, I'm so incredibly glad you posted the details of your workaround.
Thank you! I had seen the FCFLAG environment variable, but I hadn't noticed the
FFLAG variable listed just a few lines lower in the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513
--- Comment #5 from Damian Rouson ---
Thanks, Steve!
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The commands below use MPICH 3.2 installed by GCC 8 trunk dated 20171227.
Alternatively, the code can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606
--- Comment #1 from Damian Rouson ---
Is this a duplicate of Bug #81773?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
--- Comment #6 from Damian Rouson ---
Using 7.2, I still see an ICE with the reduced example from Comment 3:
$ gfortran -fcoarray=lib -c bug-78983.f90
bug-78983.f90:24:0:
end module
internal compiler error: in gfc_conv_descriptor_data_get, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
--- Comment #2 from Damian Rouson ---
Thanks for this! For anyone looking at this, I'll be glad to assist with
parallel execution testing via -fcoarray=lib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
--- Comment #4 from Damian Rouson ---
(In reply to Dominique d'Humieres from comment #3)
> AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib
> -lcaf_single.
Yes, I meant to write "-fcoarray=lib -lcaf_mpi". If the errors are
compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983
--- Comment #10 from Damian Rouson ---
I see no ICE in testing the code from Comment 3 using fortran 7.3.0, 8.2.0, and
9.0.1. I believe this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #4 from Damian Rouson ---
I don't agree that the code submitted in this bug report is non-sensical. The
submitted example is very useful for code debugging purposes. I just spent a
couple of hours trying to isolate this same bug. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #6 from Damian Rouson ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output. In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387
--- Comment #6 from Damian Rouson ---
I don't see anything in the standard related to the existence or non-existence
of components in derived-type output. In case it helps, the NAG and Intel
compilers both print "Hello world!" with the submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
This report is simply to provide a test case for Bug 64777, which was closed
for lack of a test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64777
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89840
--- Comment #2 from Damian Rouson ---
The PR was cited in the original description: Bug 64777. It was closed for
lack of a test cased and the person who closed it suggested opening a new PR if
a test case was provided so I attempted to do so. U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89840
Damian Rouson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The code below compiles cleanly with -fcoarray=single but generates a linker
error when I use -fcoarray=lib and link to MPICH and OpenCoarrays. The linking
problem goes away if the &quo
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
An ASSOCIATE construct with a substring of a deferred-length character selector
yields garbage with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90305
--- Comment #1 from Damian Rouson ---
The code gives the expected output "f" with GCC 9.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 9.1.0 gives an error message when compiling the following code, which
I believe is valid and which gfortran
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The consensus opinion on the J3 mailing list is that the code below is
standard-conforming. The Intel compiler accepts the code. gfortran 5.5, 6.4,
7.3, and
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Gfortran 8.2.0 fails to recognize the public type-bound procedure below. The
error message goes away when "module procedur
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 6.4, 7.3, and 8.2 all produce the error message below when attempting
to use a renamed type while in the same scope as the variable that motivated
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 7 and 8 accept the following invalid code when the dummy argument is
declared with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
--- Comment #3 from Damian Rouson ---
With Fortran 2018 now in Committee Draft (CD) and likely to be published this
year, it probably makes sense to close this bug report. Any features from TS
29113 that will be in Fortran 2018 have already been
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Fortran 2018 requires that compilers provide an iso_fortran_binding.h C header
file for further interoperability with C. Such a file was on the fortran-dev
branch in
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The following bug disappears if the pointer intent is switched to intent(out)
or if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659
--- Comment #1 from Damian Rouson ---
In initial comment, I meant to write "... bug disappears if the pointer intent
is switched to intent(inout)..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57093
--- Comment #3 from Damian Rouson ---
This bug report can be closed now. The submitted code completes without error
with gfortran 5.3 and 6.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57093
--- Comment #4 from Damian Rouson ---
This bug report can be closed now. The submitted code completes without error
with gfortran 5.3 and 6.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57093
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57093
--- Comment #6 from Damian Rouson ---
And it works with gfortran 4.9.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
With -fcoarray=lib, an internal compiler error occurs when compiling an EVENT
POST of an EVENT_TYPE coarray that accessed via
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
An internal compiler error (ICE) results when compiling an EVENT WAIT with an
UNTIL_COUNT argument that is an element of an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70697
--- Comment #1 from Damian Rouson ---
The ICE disappears if the UNTIL_COUNT is a scalar instead of an array element.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
--- Comment #2 from Damian Rouson ---
If I recall correctly, support for events just barely missed being included in
5.3, but will appear versions 5.4 and higher. There probably is no reason way
to port this back to the 4.9 branch because versio
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
As shown below, gfortran 6.1.0 rejects the application of the PURE attribute
consistently in a procedure interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71156
--- Comment #2 from Damian Rouson ---
Thanks!
D
> On May 18, 2016, at 12:18 AM, pault at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71156
>
> Paul Thomas changed:
>
> What|Removed
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 6, 7, and 8 generate compiler error messages when a variable in the
iso_fortran_env intrinsic model is accessed via use
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat poly-array-section-arg.f90
!! Gfortran 7.1.0 and 8.0.0 20170731 report an ICE when a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #37 from Damian Rouson ---
Bravo!
RMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
$ cat reproducer.f90
!! Associating a name with a reduced-dimension section of a
!! multidimensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82275
--- Comment #3 from Damian Rouson ---
Thanks for looking at this. Once there's a fix, it would be great if it could
be back-ported to GCC 7 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640
--- Comment #2 from Damian Rouson ---
I think this bug just bit gfortran user and Fortran enthusiast Stefano Zhagi.
Is anyone interested in fixing it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
--- Comment #3 from Damian Rouson ---
The same code causes an ICE with the 7.1.0 release. Is there a fix on the 8
branch or any related updates?
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
The transcript below demonstrates that gfortran is not performing the
synchronization required during the allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
--- Comment #1 from Damian Rouson ---
Section 9.7.1.2, paragraph 4, of the draft Fortran 2015 standard [1]:
"When an ALLOCATE statement is executed for which an allocate-object is a
coarray, there is an implicit synchronization of all active ima
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161
--- Comment #4 from Damian Rouson ---
I'll close this because another developer is going to work on it so my last
comment no longer applies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 59694, which changed state.
Bug 59694 Summary: [F03] no finalization of an unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
What|Removed |Added
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
Constraint C1589 in Draft 16-007r2 of the Fortran 2015 standard states
"A pure function shall not h
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: damian at sourceryinstitute dot org
Target Milestone: ---
gfortran 6.2.0 and 7.0.0 20161127 report an internal compiler error when an
allocatable polymorphic function appears in an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
--- Comment #4 from Damian Rouson ---
I meant to mark a different PR as invalid but marked this one mistakenly. Now
I just tried to reset its status duplicate and got the following message:
"You cannot mark bug 59694 as a duplicate of bug 67472
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78161
Damian Rouson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 59694, which changed state.
Bug 59694 Summary: [F03] no finalization of an unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
Damian Rouson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694
--- Comment #7 from Damian Rouson ---
> On Dec 4, 2016, at 12:45 AM, janus at gcc dot gnu.org
> wrote:
>
> --- Comment #5 from janus at gcc dot gnu.org ---
> (In reply to Damian Rouson from comment #4)
>> I meant to mark a different PR as inva
1 - 100 of 177 matches
Mail list logo
