--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
FIXED on the trunk (4.3).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-18 06:34 ---
Subject: Bug 33231
Author: burnus
Date: Tue Sep 18 06:34:30 2007
New Revision: 128570
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128570
Log:
2007-09-18 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #1 from pinakee dot b at xius dot com 2007-09-18 05:08 ---
Created an attachment (id=14217)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14217&action=view)
The file is where the compilation error is coming.
The attachment is the file where the compilation error is be
Following is the machine and compiler details:
bash-3.00$ gcc -v
Using built-in specs.
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure
Thread model: single
gcc version 4.0.2
Following error is generated while compiling "DynCommon.cpp" which is a file in
opensource middleware (ACE/T
--- Comment #10 from alexander at kogan dot nnov dot ru 2007-09-18 04:58
---
Hi!
Is there any progress with this bug?
We are waiting impatiently for fix!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
GCC accepts mixed-case suffix for decimal float constants.
Mixed-case suffix is not allowed in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf.
Is this a bug or extension?
test case:
double dd = 1.0dD;
--
Summary: mixed-case suffix for decimal float constants
Pro
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-09-18 00:02 ---
(In reply to comment #3)
> Do you want to commit this to gc-improv branch?
Yes. If you are OK, I'll send it to gcc-patches for gc-improv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-17 23:00 ---
(In reply to comment #3)
> (Removing pinskia from CC, as this must be spam to him)
Not really since gmail actually threads nicely and remove dups and I am
subscribed to gcc-bugs@ anyways :). The main reason why I C
--- Comment #22 from eweddington at cso dot atmel dot com 2007-09-17 22:53
---
Subject: RE: [avr-gcc] Optimization decrease performance of
struct assignment.
> --- Comment #21 from rask at gcc dot gnu dot org
> 2007-09-17 11:13 ---
> It's probably someting simple, see confi
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-17 22:37 ---
Won't fix for 4.2.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-17 22:30 ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128446
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-17 22:30 ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128490
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
The following invalid testcase triggers a broken diagnostic since at least
GCC 2.95.3:
===
int foo(int);
void bar(double d)
{
foo(d)();
}
===
bug.cc: In function 'void bar(double)':
bug.cc:5: error: 'foo(#'fix_trunc_expr' not supp
--- Comment #3 from lauras at gcc dot gnu dot org 2007-09-17 22:27 ---
Thanks for helping with this issue. Do you want to commit this to gc-improv
branch?
(Removing pinskia from CC, as this must be spam to him)
--
lauras at gcc dot gnu dot org changed:
What|Removed
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2/4.3 regression]|[4.3 regression] Broken
|Broken diagnostic:
The following invalid testcase triggers a broken diagnostic on mainline:
===
template void foo()
{
__is_class(int)();
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: '#'trait_expr' not supported by dump_expr#'
cannot be us
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33463
The following invalid testcase triggers a broken diagnostic since GCC 3.4.0:
===
namespace std
{
class type_info {};
}
template void foo()
{
!typeid(void);
}
===
bug.cc: In function 'void foo()':
bug.cc:8: error: no match for 'o
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33461
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33462
The following invalid testcase triggers a broken diagnostic since GCC 3.3.1:
===
struct A {};
void foo()
{
++__builtin_va_arg(0, A);
}
===
bug.cc:5: error: no match for 'operator++' in '++#'va_arg_expr' not supported
by dump_expr#
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
--- Comment #1 from anhvofrcaus at gmail dot com 2007-09-17 22:13 ---
Sorry for the typo in problem description paragraph. What I mean was if line 11
commented out and line 12 uncommented, the codes behave properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
The following invalid testcase triggers an ICE on mainline:
===
template struct A;
template struct A
{
struct B;
};
A a;
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: p
--- Comment #9 from jakub at gcc dot gnu dot org 2007-09-17 22:05 ---
Subject: Bug 33423
Author: jakub
Date: Mon Sep 17 22:05:40 2007
New Revision: 128554
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128554
Log:
PR middle-end/33423
* builtins.c (expand_builtin_
The following invalid testcase triggers an ICE since GCC 4.2.1:
===
union A
{
int &i;
};
void foo()
{
A();
}
===
bug.cc:3: error: 'A::i' may not have reference type 'int&' because it is a
member of a union
bug.cc: In function 'v
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33460
The following invalid testcase triggers an ICE since GCC 3.0:
===
struct A
{
struct
{
struct { static int i; };
void foo() { i; }
};
};
===
bug.cc:5: error: 'int A::i' invalid; an
anonymous struct can only have non-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 21:56 ---
Confirmed, inlining and RVO and RSO are interacting together interestingly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33459
The following valid testcase triggers an ICE on mainline
when compiled with "-O":
===
inline void foo(int* p, int n)
{
for (; n > 0; --n, ++p)
*p = 0;
}
struct A
{
int x[2];
A() { foo(x, 2); }
};
inline A getA() { return A(); }
struct B
{
A a;
B();
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-17 20:09 ---
Queued for 4.4!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-09-17 20:06
---
No 4.3 pending patch anymore.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Othe
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-17 20:07 ---
They're still there, but obviously no longer 4.3 material.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
Some vendors seemingly offer to set the filename of a pre-connected unit via an
environment variable.
I'm not sure we need this, but some other compilers seem to have it and it is
seemingly used:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/16d2c1d82a05edb4
--
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-17 19:22 ---
I would strongly discourage adding this feature. A long time ago,
either Paul Brook or Steven Bosscher and I exchanged email about
the use of environmental variables to control various aspects of
gfortran. In the end
--- Comment #10 from pcarlini at suse dot de 2007-09-17 19:18 ---
Not actively working on it (for now)
--
pcarlini at suse dot de changed:
What|Removed |Added
Ass
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|Wrong system.ads for --with-|[4.3 Regressi
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 19:05 ---
Confirmed. Reverting r127960 helps.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The object renaming does not behave properly as demonstrated with the test
codes below. Note that line 11 of message_services.adb contains the problem. In
addition, if line 11 is commented out and line 12 in uncommented, the codes
behave properly.
package Message_Services is
type Message_Code i
--- Comment #4 from manu at gcc dot gnu dot org 2007-09-17 17:56 ---
I think this is confirmed as a feature that would be nice to have. So the
install instructions should behave like the OpenMP manual here
http://gcc.gnu.org/onlinedocs/ and we will end up with:
http://gcc.gnu.org/instal
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 17:39 ---
For the warning that TRANSFER contains partially undefined values, see also PR
33037. For MERGE, see PR 33455
Independent of those, the following valid program still gives an ICE (if one
removes the "20" in transfer
--- Comment #2 from manu at gcc dot gnu dot org 2007-09-17 17:32 ---
I think Andrew is right. If you think that this is still an issue, please
reopen.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from gcc at abeckmann dot de 2007-09-17 17:35 ---
Created an attachment (id=14216)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14216&action=view)
minimal testcase
The ICE only occurs with -O3 and above.
$ /suse/NOBACKUP/gcc/gcc-4.2-branch/bin/g++ -v -O3 -fopenmp
See 31610 for another example.
"13.7.75 MERGE (TSOURCE, FSOURCE, MASK)"
"FSOURCE shall be of the same type and type parameters as TSOURCE."
NAG f95:
Error: merge_char_3.f90, line 4: Unequal character lengths (2 and 3) in MERGE
intrinsic
Error: merge_char_3.f90, line 5: Unequal character lengths (
--- Comment #2 from pcarlini at suse dot de 2007-09-17 17:22 ---
I can't reproduce the problem with current (128551) mainline. Likely a
transient issue, otherwise, please reopen.
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #5 from don-gcc at isis dot cs3-inc dot com 2007-09-17 16:31
---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation fault]
Nick Clifton writes:
> There are several possibilities:
...
I ended up following the recommendation below - worked fine.
I installed t
--- Comment #22 from ubizjak at gmail dot com 2007-09-17 16:43 ---
Fixed in mainline, still (latent) present on 4.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 16:29 ---
Simple patch; catches if result size > source size (cf. example in bug 31610
comment 0). However, it does not catch if result size < LHS variable. (Example
in this PR.)
Index: simplify.c
=
--- Comment #21 from rakdver at gcc dot gnu dot org 2007-09-17 15:39
---
Subject: Bug 26449
Author: rakdver
Date: Mon Sep 17 15:38:48 2007
New Revision: 128549
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128549
Log:
PR rtl-optimization/26449
* loop-invariant.
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 15:56 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2007-09-17 15:55 ---
Subject: Bug 33106
Author: burnus
Date: Mon Sep 17 15:55:22 2007
New Revision: 128550
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128550
Log:
2007-09-17 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 15:43
---
Closing, please reopen when you get time to rebuild and post the error.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 15:26 ---
> On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I
> get a short series of invalid read beginning with:
FX, which version of gfortran are you using? I cannot reproduce it (with
valgrind) u
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-09-17 15:12
---
Subject: Bug 33406
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128547
Log:
PR middle-end/33348
PR target/33406
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-09-17 15:12 ---
Subject: Bug 33348
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128547
Log:
PR middle-end/33348
PR target/33406
*
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-09-17
14:57 ---
To clarify, what I meant to say in the above comment was that I am concerned if
Zdenek's patch may convert this PR into a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-09-17
14:52 ---
On powerpc-apple-darwin9, the patch Zdenek is checking in...
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01380.html
suppresses the build problems in Java...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #11 from dominiq at lps dot ens dot fr 2007-09-17 13:59 ---
Subject: Re: [4.3 Regression] At revision 128385
Bootstraping PPC Darwin still fail in Java
Did you try to bootstrap with Java with the one line patch in:
http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01311.html
It
--- Comment #42 from rguenth at gcc dot gnu dot org 2007-09-17 13:11
---
Still slow.
cfg cleanup : 7.10 (10%) usr 0.16 (10%) sys 7.26 (10%) wall
625 kB ( 1%) ggc
tree VRP : 27.40 (39%) usr 0.39 (23%) sys 27.91 (38%) wall
7602 kB (11%) ggc
CPRO
--- Comment #4 from nickc at redhat dot com 2007-09-17 12:08 ---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation
fault]
Hi Don,
> Thank you both for your replies. I have now built binutils 2.18.
> However I'm not root on this machine and so cannot install it in the
--- Comment #5 from opichals at seznam dot cz 2007-09-17 11:35 ---
Yes, I have checked the ODR definition and it is really the fact that the code
violates that. Thank you for your explanations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32549
--- Comment #21 from rask at gcc dot gnu dot org 2007-09-17 11:13 ---
It's probably someting simple, see config.log. Like I said, the patch is a
quick and dirty one and the AVR back end can use more work than that, most of
which means deleting patterns. Examples: All and, ior, xor, one_c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 11:03 ---
Confirmed. Looks like we try to build a multiplication with ptr * int:
(gdb) bt
#0 fancy_abort (
file=0xf27848 "/space/rguenther/src/svn/pointer_plus/gcc/tree.c",
line=3110, function=0xf291bf "build2_stat
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42
---
Closing the bug, after adding a reduced testcase to the testsuite.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42
---
Subject: Bug 33449
Author: fxcoudert
Date: Mon Sep 17 10:42:29 2007
New Revision: 128543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128543
Log:
PR middle-end/33449
* gfortran.dg/pr3344
--- Comment #5 from andrew dot stubbs at st dot com 2007-09-17 10:30
---
Subject: Re: New: [SH4] performance regression between
3.4.6 and 4.x
nbkolchin at gmail dot com wrote:
> Our target hardware has SH7750 processor running in little endian mode under
> RTEMS. Unfortunetaly there
nbkolchin at gmail dot com wrote:
Our target hardware has SH7750 processor running in little endian mode under
RTEMS. Unfortunetaly there is no way to boot linux there.
After lurking inside backend sources, I found that m4 has several variants in
GCC 4.x: m4-100, m4-200, etc. I've tried to compi
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:16
---
I'm making this a meta-bug to monitor our improvement on newlib targets.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from kari-matti dot pulkkinen at comptel dot com 2007-09-17
10:01 ---
Got the same error with 4.2.1:
/temp/cpt2k4p/gcc/HP-UXita/./gcc/xgcc -B/temp/cpt2k4p/gcc/HP-UXita/./gcc/
-B/vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/bin/
-B/vobs/prod/tools/gnu/gcc/HP-UXita/i
--- Comment #5 from irar at il dot ibm dot com 2007-09-17 09:54 ---
(In reply to comment #4)
> Anyway, I am trying to reproduce this ICE on x86_64-linux now, with the
> current
> trunk (128538).
It doesn't ICE for me. (The loop gets vectorized).
Ira
--
http://gcc.gnu.org/bugzilla
/tmp/cvs/gcc-20070916/Build/./gcc/xgcc -B/tmp/cvs/gcc-20070916/Build/./gcc/
-B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/bin/
-B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/include -isystem
/tmp/cvs/gcc-20070916
--- Comment #2 from victork at gcc dot gnu dot org 2007-09-17 09:37 ---
Subject: Bug 33319
Author: victork
Date: Mon Sep 17 09:37:31 2007
New Revision: 128539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128539
Log:
PR tree-optimization/33319
* tree-vect-analy
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-17 09:33
---
On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I
get a short series of invalid read beginning with:
==1628== Invalid read of size 1
==1628==at 0xAEA1F0: htab_hash_string (hashtab.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 09:14 ---
This is related to pointer plus.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 09:05 ---
Please provide a complete testcase that shows the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451
--- Comment #4 from irar at il dot ibm dot com 2007-09-17 08:59 ---
(In reply to comment #3)
> I can reproduce that on x86_64-linux with trunk rev. 128442.
Dorit's fix is revision 128514, so it is not supposed to work on 128442...
Anyway, I am trying to reproduce this ICE on x86_64-lin
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 08:53 ---
Jakub Jelinek wrote (in PR 33439, but seemingly regarding this PR):
> Pedantically this is not a bug. If an omp sentinel doesn't have the desired
> form, it should be handled as a normal comment. As the preceeding l
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:40
---
Yep, this was fixed. Sorry.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:39
---
I can reproduce that on x86_64-linux with trunk rev. 128442. Severity set to
critical, as this is LAPACK.
Program received signal SIGSEGV, Segmentation fault.
vect_get_vec_defs_for_stmt_copy (dt=0x7fff713d44c0,
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 08:33 ---
I guess so. All the testcases rely on either availability of cexp() or
sincos().
For the former via TARGET_C99_FUNCTIONS, for the latter via TARGET_HAS_SINCOS.
But it is interesting that -59 fails, as the transform
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-17 08:21 ---
> Pedantically this is not a bug. If an omp sentinel doesn't have the desired
> form, it should be handled as a normal comment.
I think your comment is with regards to PR 33445 and not regarding this PR
(PR33439).
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-17 08:18 ---
Pedantically this is not a bug. If an omp sentinel doesn't have the desired
form, it should be handled as a normal comment. As the preceeding line
doesn't end with &, then !$omp& is not a valid omp sentinel (as !$omp
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-17 08:05 ---
Jakub, do you agree that this is a bug or is this no bug?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 07:40 ---
How about giving a diagnostic as ifort does:
fortcom: Error: test2.f90, line 93: Syntax error, found '&' when expecting one
of: ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE
CHARACTER ...
!$omp& default(shared)
-
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-17 07:16 ---
Why do you think that is a bug?
Please read OpenMP 2.5, 2.1.1 (Fixed Source Form Directives) and 2.1.2
(Free Source Form Directives). Continuation is done very differently between
fixed and free form. So, what are yo
90 matches
Mail list logo
