Code below generates an incorrect warning:
$ gcc -Wall -c temp.c
temp.c:4: warning: format %x expects type unsigned int, but argument 2 has
type unsigned int
$ cat temp.c
int format (const char * f, ...) __attribute__ ((format (printf, 1, 2)));
void bar (unsigned int x)
{
format ("%x",
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-06 08:34 ---
Reduced test case:
program try_cg0071
type seq
integer ia(10)
end type
TYPE(SEQ) UDA1R
type(seq) uda(1)
do j1 = 1,10
uda1r%ia(j1) = j1
enddo
uda = u
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-06 08:37
---
Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-06 08:37
---
Likewise...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from dennis dot wassel at googlemail dot com 2008-10-06
09:33 ---
Created an attachment (id=16464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16464&action=view)
example
s|.FALSE._C_BOOL|.FALSE.| to cause f951 to hang instead of segfaulting.
--
http://gcc.gn
--- Comment #1 from joseph at codesourcery dot com 2008-10-06 11:58 ---
Subject: Re: New: Segmentation Fault Exception with -O and
signed array index
On Mon, 6 Oct 2008, gcc at jme dot de wrote:
> The following code produces a segmentation fault when compiled with -O.
> Environment
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--e
The following code produces a segmentation fault when compiled with -O.
Environment is GCC V4.2.2 (also tested with 4.1.2) on AVR32 Linux target.
Cross compiled on Cygwin.
With GCC V3.4.4 on Cygwin Target it works correct.
Even when I insert a printf("."); between the if and the for the code works.
The following testcase of (I think) valid Fortran90 code, shows a strange
error. It copies all characters of a text string except for the first
character, which for some unknown reason is replaced by a space.
The essential element seems to be the use of the expression len(a)+1 to
dimension the size
f951 hangs or segfaults on this invalid piece of code, after printing the
correct diagnostic message.
The example is very sensitive to changes (even comments or whitespace), causing
f951 to either hang, segfault or abort gracefully; this version provokes a
segfault. The compiler can be provoked to
--- Comment #33 from nickc at redhat dot com 2008-10-06 12:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
> http://people.netfarm.it/~sherpya/gcc/info.7z
Just a quick check: If you build with "-fno-common" does the executable
then
With revision 140892 I get the following failures in 32 bit mode (but not with
-m64):
FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test
FAIL: gfortran.dg/large_real_
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-06 13:27 ---
I have forgotten to say that revision 140513 is working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37747
With revision 140892 I get the following failures in 32 and 64 bit modes:
FAIL: gfortran.dg/random_3.f90 -O0 execution test
FAIL: gfortran.dg/random_3.f90 -O1 execution test
FAIL: gfortran.dg/random_3.f90 -O2 execution test
FAIL: gfortran.dg/random_3.f90 -O3 -fomit-frame-pointer execution
subroutine subr (m, n, a, b, c, d, p)
implicit none
integer m, n
real a(m,n), b(m,n), c(n,n), d(m,n)
integer p(n)
d = a(:,p) - matmul(b, c)
end subroutine
implicit none
integer i
real a(3,2), b(3,2), c(2,2), d(3,2)
integer p(2)
a = reshape ((/(i, i = 1, 6)/), (/3, 2/))
b = 1
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-10-06 14:07 ---
Just to check whether the propagation of the conflicting hard regs in
ira_flatting really is the main problem I've tried the following patch. With
that patch the ira branch bootstraps on s390x.
Index: gcc/ira-build.
--- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 ---
$ nm ffmpeg_g.exe |grep ff_cos_16
00dd84e0 B _ff_cos_16
00de04c0 B _ff_cos_16384
except snow and svq1 tests, crashing because of bugs in tree opts on win32
sse code is working fine
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-06 14:47 ---
Your code works if you fix the bug. You have two choices
program Test_StrCopy
character(len=50) :: a
character(len=51) :: b
a = "abcdefg"
call copy(a,b)
end program Test_StrCopy
or
subroutine copy(a,b)
ch
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #16 from vmakarov at gcc dot gnu dot org 2008-10-06 15:35
---
Subject: Bug 37535
Author: vmakarov
Date: Mon Oct 6 15:34:26 2008
New Revision: 140906
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140906
Log:
2008-10-06 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-06 15:55 ---
We need a testcase for this (preprocessed source of opsum.c).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-06 15:59 ---
This will invoke
for (i=0; i<0; i++)
which invokes undefined behavior on signed integer overflow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
Sent from my iPhone
On Oct 6, 2008, at 5:09 AM, Denis <[EMAIL PROTECTED]> wrote:
Hi,
I use gcc:
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --
with-local-prefix=/usr/local --infodir=/usr/
--- Comment #2 from linuxl4 at sohu dot com 2008-10-06 16:21 ---
I really don't know how to make the preprocessed source ,since no include path
is given. the Makefile only give the message such as:
CC ../../../../src/mpi/coll/opsum.c
I will study it.someone maybe can hel
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-06 16:31 ---
If you read the URL gcc printed ( http://gcc.gnu.org/bugs.html ), you'll know
how to produce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
--- Comment #35 from nickc at redhat dot com 2008-10-06 16:43 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi sherpya,
> --- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 ---
> $ nm ffmpeg_g.exe |grep ff_cos_16
> 0
--- Comment #36 from sherpya at netfarm dot it 2008-10-06 17:14 ---
so how with -fno-common can make aligned work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #37 from nickc at redhat dot com 2008-10-06 17:24 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
Hi,
> so how with -fno-common can make aligned work?
Hang on - I thought that you had said that when ffmpeg_g.exe was built
with
--- Comment #38 from sherpya at netfarm dot it 2008-10-06 17:27 ---
yes alignment works, and even my test align program with 4.2 without patches
gives correct alignment to local and global symbols
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 0
16 -> 26
while testing ffmpeg compiled with gcc 4.3.3 from 4.3 trunk
I got a lot of crashes especially in snow encoding testcase
by using:
-fno-tree-dominator-opts -fno-tree-vrp -fno-dce -fno-tree-ch
I get no crashes
gcc 4.4 has same problems,
I've already filled a bug about tree-ch, that corrupts the s
--- Comment #39 from nickc at redhat dot com 2008-10-06 18:16 ---
Subject: Re: [cygming] Invalid alignment for SSE store
to .comm data generated with -O3
> yes alignment works, and even my test align program with 4.2 without patches
> gives correct alignment to local and global symbo
On x86 backend, TARGET_USE_HIMODE_FIOP is never used.
--
Summary: TARGET_USE_HIMODE_FIOP is unused
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
AssignedTo: unassi
--- Comment #2 from hjl dot tools at gmail dot com 2008-10-06 18:40 ---
It is used in
http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg00769.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from hjl dot tools at gmail dot com 2008-10-06 18:41 ---
It is removed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|N
TARGET_USE_SIMODE_FIOP is unused in x86 backend.
--
Summary: TARGET_USE_SIMODE_FIOP is unused
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
AssignedTo: unassigned
--- Comment #40 from sherpya at netfarm dot it 2008-10-06 18:54 ---
I mean that with -fno-common alignment works, even with non patched 4.2, my
question is due to the fact that it's not so clear for me what no-common does
and adding -fno-common what are side effects?
do using something
>From http://gcc.gnu.org/ml/fortran/2008-10/msg00045.html :
$ cat foo.f90
character(len=16) :: string, string2
string='BIG_ENDIAN'
open(unit=13,form='unformatted',file='gftest.dat',convert='big_endian',status='UNKNOWN')
write(13) string
close(13)
end
$ gfortran foo.f90
$ ./a.out
$ od -t x1
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-06 19:34 ---
It is fixed by TARGET_USE_MODE_FIOP.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-06 19:34 ---
It is used by TARGET_USE_MODE_FIOP.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-06 19:53 ---
I think the true bug is that -fbounds-check misses the problem. NAG f95 prints
at run time:
CHARACTER actual arg LEN=50 shorter than dummy arg LEN=51
Program terminated by fatal error
--
http://gcc.gnu.org/bu
GFortran is slower with I/O than g77 was (I think that was known already).
But 4.4 is even slower than 4.3 in certain cases, e.g.:
a simple program to count lines:
countlines.f
---
PROGRAM countlines
C Count lines on stdin
I=0
DO
READ(*,*,END=1)
I=
--- Comment #41 from dannysmith at users dot sourceforge dot net
2008-10-06 20:18 ---
(In reply to comment #35)
> As I suspected. The PE/COFF file format does not provide for specifying
> the alignment of commons.
>
> Hmm, I wonder if gcc should complain if it finds aligned commons
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
GCC Version: 4.2.3
Host: Ubuntu 8.04
When I compile the following code:
#include
typedef struct person {
char name[40];
int age;
} Person;
static Person make_person(void);
int main(void) {
printf("%s\n", make_person().name);
return 0;
}
static Person make_person(void) {
static Per
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:17 ---
No other target has this issue except Win32. I am going to say mingw support
for alloca is broken somehow.
--
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
|
# gcc *.i -combine -O3 -c -o udns.o
dia-submit/udns_init.c: In function dns_set_srch_internal:
dia-submit/udns_init.c:47: internal compiler error: in
get_addr_dereference_operands, at tree-ssa-operands.c:1698
Because it only appears to happen when building with multiple input files, I
have attac
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:18 ---
Was this fixed by:
2008-10-02 David Edelsohn <[EMAIL PROTECTED]>
* config/rs6000/rs6000.c (USE_FP_FOR_ARG_P): Revert
TARGET_DOUBLE_FLOAT, TARGET_SINGLE_FLOAT.
(function_arg_advance): Condit
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:25 ---
I don't get a seg fault on ppc but I do on x86. It works correctly for the C++
front-end where the array decays into a pointer.
The warning is also bogus but it shows what the issue is really.
--
pinskia at gcc
--- Comment #1 from zlynx at acm dot org 2008-10-06 21:25 ---
Created an attachment (id=16465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16465&action=view)
Gzipped Tar of .i files for bug reproduction
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37756
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:25 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from joseph at codesourcery dot com 2008-10-06 21:39 ---
Subject: Re: New: Mistaken Segmentation fault
On Mon, 6 Oct 2008, charpour at gnet dot gr wrote:
> printf("%s\n", make_person().name);
make_person().name is a non-lvalue array, so it only decays to a pointer
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|READ I/O Performance|[4.4 Regression] READ I/O
|regression from 4.3 to 4
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 21:53 ---
>The failure started with r132589
Though it pushed the code limit up on the functions inside insn-automata.o.
I wonder if we could get a way to disable and enable some scheduling for the
first stage where we only ne
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-06 21:55 ---
DEF_GCC_BUILTIN(BUILT_IN_BSWAP32, "bswap32", BT_FN_UINT32_UINT32,
ATTR_CONST_NOTHROW_LIST)
This is caused by the fact __builtin_bswap32 uses uintSItype instead of the
normal unsignedint types.
--
http:/
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-06 21:56 ---
DEF_FUNCTION_TYPE_1 (BT_FN_UINT32_UINT32, BT_UINT32, BT_UINT32)
DEF_PRIMITIVE_TYPE (BT_UINT32, uint32_type_node)
Instead of using:
DEF_PRIMITIVE_TYPE (BT_UINT, unsigned_type_node)
But we need to use the 32bit type
When -Os is enabled, gcc generates a loop where there is none.
gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=
--- Comment #2 from sherpya at netfarm dot it 2008-10-06 22:34 ---
this problem started with 4.3, 4.3.2 on debian linux hasn't these problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
--- Comment #1 from rick at efn dot org 2008-10-06 22:36 ---
Created an attachment (id=16466)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16466&action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
--- Comment #2 from rick at efn dot org 2008-10-06 22:37 ---
Created an attachment (id=16467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16467&action=view)
i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37757
powerpc-eabispe-gcc -v -save-temps -I/home/patrick/src/e7/prex
-I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include
-nostdinc -fsingle-precision-constant -mabi=no-spe -gdwarf-2 -Os -ansi
-fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith
-std=gnu99 -fno-st
--- Comment #1 from patrick at motec dot com dot au 2008-10-06 23:06
---
Created an attachment (id=16468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16468&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37758
--- Comment #2 from patrick at motec dot com dot au 2008-10-06 23:10
---
The problem appears to be that the loop
for (; y < pa; y++) {
asm(" mullw16,%3,%4 \n\t"
" mulhwu 17,%3,%4 \n\t"
" addc 16,16,%0 \n\t"
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 23:12 ---
You either need to require [reg+offset] or use stw%U0%X0 for the "m"
constraint.
Likewise for lwz.
The other question is why are you using inline-asm in the first place for the
load/stores.
--
pinskia at gcc do
--- Comment #42 from brian at dessent dot net 2008-10-06 23:29 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
When you are comparing gcc 4.2 to current trunk, are you keeping the
linker (binutils) version the same? As mentioned in comment
--- Comment #4 from patrick at motec dot com dot au 2008-10-06 23:31
---
I'm not personally responsible for this code, it is part of the LibTomMath
library.
Changing the constraint to either =o or =g appears to resolve the problem (will
need to test).
--
patrick at motec dot com do
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-06 23:37 ---
Hmm, works with -march=i668 as that enables ifcvt.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #43 from sherpya at netfarm dot it 2008-10-07 01:32 ---
binutils 2.18.91.20080917 on both
there are changes for the local alignment in the gas code but gcc does not use
them without my attached gcc_align_fix.diff patch (not sure 100%)
newer binutils are not working well on m
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-10-07 02:06
---
This still fails after the patch to fix PR 37535 on i386-darwin8.11.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-10-07 02:54
---
Thomas, any ideas and do you have time to investigate this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37753
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-10-07 02:55
---
I am a bit stacked up, but I will explore this one a bit.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from johnson at cs dot uiuc dot edu 2008-10-07 02:58 ---
Created an attachment (id=16469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16469&action=view)
fruit.f90, illustrates huge .o file, requires fruit_util.f90
I think I have a testcase that shows this bug. I
--- Comment #4 from johnson at cs dot uiuc dot edu 2008-10-07 02:58 ---
Created an attachment (id=16470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16470&action=view)
fruit_util.f90, needed to compile fruit.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-10-07 03:58
---
strace shows no difference in number of system calles between 4.3 and 4.4.
gprof has some interesting things to see.
With 4.4:
% cumulative self self total
time seconds se
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-07 04:25
---
With the following test program I created a file to read useing a write in
place of the read.
program testio
implicit none
integer :: i, k
real :: x
real(kind=8) :: y
complex :: c
ch
--- Comment #4 from linuxl4 at sohu dot com 2008-10-07 05:02 ---
Created an attachment (id=16471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16471&action=view)
the preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
powerpc-eabispe-gcc -I../ -I/home/patrick/src/e7/prex
-I/home/patrick/src/e7/prex/include -I/home/patrick/src/e7/prex/usr/include
-nostdinc -fsingle-precision-constant -mno-spe -gdwarf-2 -Os -ansi
-fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith
-std=gnu99 -fno-stack-protector
--- Comment #5 from linuxl4 at sohu dot com 2008-10-07 05:07 ---
gcc -O3 -march=pentium4 -c opsum.c fails.
instead,
gcc -O2 -march=pentium4 -c opsum.c
or
gcc -O3 -march=i686 -c opsum.c
pass.
--
linuxl4 at sohu dot com changed:
What|Removed |Add
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:07
---
Created an attachment (id=16472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16472&action=view)
preprocessed source
after compiling, evstdd and evldd instructions are emitted even though the
-mno-spe flag
powerpc-eabispe-gcc -I../include -I/home/patrick/src/e7/prex/dev/include
-I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include
-I/home/patrick/src/e7/prex/include -nostdinc -fsingle-precision-constant
-mcpu=common -mfloat-gprs=single -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall
-Wun
--- Comment #1 from patrick at motec dot com dot au 2008-10-07 05:49
---
Created an attachment (id=16473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16473&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37760
Revision 140916:
http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00117.html
caused
+FAIL: abi/demangle/abi_examples/20.cc execution test
+FAIL: abi/demangle/abi_text/02.cc execution test
+FAIL: abi/demangle/regression/cw-16.cc execution test
--
Summary: [4.4 Regression]: Revision 140916
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-07 05:58 ---
Revision 140914 is OK and revision 140917 is bad.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
87 matches
Mail list logo
