During the make install -bnoquiet I have the following errors:
SHLIB_EXT='.a' \
SHLIB_MULTILIB='' \
SHLIB_MKMAP='../../gcc-4.0.0/gcc/mkmap-flat.awk' \
SHLIB_MKMAP_OPTS='' \
SHLIB_MAPFILES='../../gcc-4.0.0/gcc/libgcc-std.ver ../../gcc-
4.0.0/gcc/config/rs6000/libgcc-ppc64.ver' \
--- Additional Comments From dirtyepic dot sk at gmail dot com 2005-07-11
06:24 ---
Has this been backported to the 4.0 branch now that it's open again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10611
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-07-11
07:54 ---
Almost there:
Index: Makefile.tpl
===
RCS file: /cvs/src/src/Makefile.tpl,v
retrieving revision 1.135
diff -p -u -r1.135 Makefile.tpl
---
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
08:03 ---
Subject: Bug 22340
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-11 08:03:09
Modified files:
. : ChangeLog Makefile.in Makefile.tpl
I compiled the C compiler on Mandrake Linux 10.1 (running virtually on VMware).
The compile died with this message:
../../gcc-4.0.1/gcc/toplev.c: In function 'toplev_main':
../../gcc-4.0.1/gcc/toplev.c:548: sorry, unimplemented: inlining failed in call
to 'floor_log2': redefined extern inline
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
08:48 ---
More compact C++ testcase:
==
struct A
{
char c;
int i;
};
A a;
struct B
{
char c, d;
};
union C
{
A *p;
B *q;
C() : p(a) {}
char foo() { return q-d;
Yet another ICE in first_vi_for_offset. Compile the following code snippet
with g++ -O:
=
struct A { A(); };
struct B : A
{
A a;
};
struct C : B { };
C c;
=
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
with: /scratch/gcc/configure --quiet
--prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95
--enable-mapped-location --with-gmp=/afs/mpa/data/martin/mygmp
Thread model: posix
gcc version 4.1.0 20050711 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -quiet -v
--
What|Removed |Added
Keywords||ice-on-invalid-code
Known to fail||4.1.0
Known to work|
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
10:47 ---
Reduced testcase (compile with gcc -O -std=gnu99):
__complex__ double foo (__complex__ double x)
{
return 1.0 / x * -1.0i;
}
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
11:02 ---
Fixed on mainline by Nathan's patch for PR21799.
--
What|Removed |Added
--
Bug 21799 depends on bug 8271, which changed state.
Bug 8271 Summary: Templates and pointers to const member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8271
What|Old Value |New Value
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
12:05 ---
Subject: Bug 22102
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-11 12:04:51
Modified files:
libstdc++-v3 :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
12:05 ---
Subject: Bug 21244
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-11 12:04:51
Modified files:
libstdc++-v3 :
--- Additional Comments From john at karsner dot net 2005-07-11 12:29
---
(In reply to comment #3)
One more question:
what does the output of:
/usr/local/i686-pc-linux-gnu/bin/ld --version
give?
I notived this was still in a waiting state. Is there anything else you
require??
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-11
12:33 ---
Subject: Re: [4.1 Regression] ACATS ICE
cc40001 in first_vi_for_offset, at tree-ssa-structalias.c:2566
On Mon, 2005-07-11 at 08:48 +, reichelt at gcc dot gnu dot org
wrote:
--- Additional
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
12:57 ---
Subject: Bug 20563
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-11 12:57:06
Modified files:
gcc/cp :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
13:01 ---
Now also fixed on the 4.0 branch.
--
What|Removed |Added
Status|ASSIGNED
This warns with -Weffc++, but shouldn't:
class Foo {
Foo(constFoo); // disable
Foooperator=(const Foo); // disable
public:
Foo() {}
~Foo() {}
};
class Bar : public Foo { void * mPointerMember; };
The compiler knows at this point that any attempt to generate a op= or copy
Bootstrapping fails after configure for libgfortran has completed:
...
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing default-1 commands
Adding multilib support to Makefile in ../../../../gcc-4.0.1/libgfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
13:58 ---
THis is a bug in your glibcc and/or kernel headers I forgot which one. Please
report this to Mandrake.
--
What|Removed |Added
--
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
--- Additional Comments From pinskia at physics dot uc dot edu 2005-07-11
14:17 ---
Subject: Re: ICE in emit_move_insn, at expr.c:3142
On Jul 11, 2005, at 6:47 AM, reichelt at gcc dot gnu dot org wrote:
Do you want to add this as a testcase, since the one in PR22356
only triggers
On Jul 11, 2005, at 6:47 AM, reichelt at gcc dot gnu dot org wrote:
Do you want to add this as a testcase, since the one in PR22356
only triggers with an additional patch of yours?
Yes Please add the testcase as we don't have that many complex tests
in GCC's testsuite.
-- Pinski
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-07-11
14:18 ---
/bin/sh: syntax error at line 1: `(' unexpected
/bin/sh is not supported on Solaris. Please follow the instructions at:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
--
What
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
14:24 ---
Subject: Bug 10611
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-11 14:24:07
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
14:26 ---
You have to do make bootstrap/make before you do a make install.
Does that help?
--
What|Removed |Added
[EMAIL PROTECTED]:::~/tmp/gcc-head/objdir make install
/bin/sh ../srcdir/mkinstalldirs /home/4/wilx /home/4/wilx
make[1]: Entering directory `/home/4/wilx/tmp/gcc-head/objdir/fixincludes'
make[1]: *** No rule to make target `../libiberty/libiberty.a', needed by
`full-stamp'. Stop.
make[1]:
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-11
14:27 ---
One problem seems to be that we place the attribute for mysinfp on the decl and
not on the type. Why we do have both, and they can mis-match is a mystery to
me anyway ;)
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
14:28 ---
I don't get any ICE with a build last night:
GNU C++ version 4.1.0 20050711 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050711 (experimental).
GGC heuristics: --param ggc
--- Additional Comments From aldyh at gcc dot gnu dot org 2005-07-11 14:42
---
I have just backported to the 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10611
--- Additional Comments From mckinlay at redhat dot com 2005-07-11 15:44
---
There might be a way to implement this without additional _Jv_AllocObject cost
and without adding new ABI tables.
If abstract classes and interfaces were given a zero or negative value in their
size field, I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
15:57 ---
Confirmed, I missed part of the testcase when testing.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
15:58 ---
Here is the backtrace:
#0 most_specialized_instantiation (instantiations=0xb7d84570) at
/home/peshtigo/pinskia/src/gnu/
gcc/src/gcc/cp/pt.c:10723
#1 0x080a071b in determine_specialization
The following code snippet causes an ICE (3.4 branch only)
when compiled with gcc -O2 -ffast-math on i686-pc-linux-gnu
===
double atan (double);
void foo()
{
double x, y;
do
{
goto L2;
L1:
if (x) goto L1;
L2:
x += atan (y);
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
16:05 ---
The new PR for the problem in comment #3 is PR 22409.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:10 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-11
16:15 ---
It doesn't link because of [templ.expl.spec]:
An explicit specialization of a static data member of a template is a
definition if the declaration includes an initializer; otherwise, it
is a
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:26 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:28 ---
Confirmed, a regression from 4.0.0.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:29 ---
Confirmed.
--
What|Removed |Added
Severity|normal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:29 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:35 ---
Confirmed. I think fixing PR 19816 will also fix this.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
16:37 ---
Can people start filing new bugs as the orginal problem has been fixed now.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-07-11 17:46
---
Ok, we can close it, then.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
17:55 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
17:58 ---
Closing as invalid based comment #7.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
17:59 ---
Does this work in 4.0.x?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16442
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
The negative-z-descriptor.f90 test for PR 22217 fails on the statement
using '(B65)' format with Fortran runtime error: Error 0. The error occurs in
list_read.c:next_char() when salloc_r returns NULL.
Leading up to this point, transfer.c:formatted_transfer() was invoked with
format B. As
--
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
18:28 ---
Subject: Bug 22404
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-11 18:28:36
Modified files:
gcc: ChangeLog print-tree.c
--- Additional Comments From roessner at rbg dot informatik dot
tu-darmstadt dot de 2005-07-11 18:54 ---
(In reply to comment #1)
/bin/sh: syntax error at line 1: `(' unexpected
/bin/sh is not supported on Solaris. Please follow the instructions at:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-07-11
19:20 ---
Ok, rebuilt with CONFIG_SHELL=/bin/bash; export CONFIG_SHELL.
Did you use an absolute path to invoke configure, as strongly recommended? FWIW
I just bootstrapped 4.0.1 on Solaris 2.5.1, 2.6, 7, 8, 9
Using crosstool get the following:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o stub-objc.o attribs.o
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
19:38 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00771.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
19:38 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00771.html.
--
What|Removed |Added
assert(i) gives will never be executed on Linux.
assert(0) and assert(1) are silent.
I've tried to vary the assert() definition, e.g. give __assert_fail()
return type int and do (void)(i ? 0 : (0 __assert_fail(...))), but
only removing __attribute__((noreturn)) seems to kill the warning.
I don't
--- Additional Comments From bh at techhouse dot brown dot edu 2005-07-11
19:42 ---
I get a similar error on my pentium-3 box, configuring with just:
/afs/cs/usr/bhudson/gcc/gcc-cvs-head/configure --enable-languages=c,c++
and
gmake CFLAGS=-O2 BOOT_CFLAGS=-O2 profiledbootstrap
struct C
{
int a;
int *b;
int *c1 (int x) { return new int[sizeof (int) * x]; }
void c2 (int *x, int *y, int z)
{
for (int i = 0; i z; i++)
y[i] = x[i];
}
C (int x = 0) : a (x)
{
if (a)
{
b = c1 (a);
for (int i = 0; i a; i++)
b[i] =
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
19:50 ---
The warning is correct as there is an assigment for a temporary.
The assert should be written like:
void abort(void);
void f(int i)
{
i ?(void) 0 : abort();
}
Please report this bug to glibc.
--
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-11
19:52 ---
Erik,
Have you checked the parse tree for this? It looks OK, from a very
casual look, but the parse tree would be the clincher.
After comments from Tobi I posted a new patch here:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
19:56 ---
Confirmed, this might be a latent bug on the mainline.
--
What|Removed |Added
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-11
20:02 ---
Subject: Re: interface body has incorrect scope
That seems to be as good as one could want!
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20363
FAIL: 23_containers/set/explicit_instantiation/1.cc (test for excess errors)
has appeared on mainline on i686-pc-linux-gnu (gcc-testresults shows other
platforms as well) between 20050710 and 20050711 (both at 07:00 UTC).
/scratch/gcc/nightly-2005-07-11-mainline/i686-pc-linux-gnu/build_gcc/build
--
What|Removed |Added
Keywords||alias, ice-on-valid-code
Target Milestone|--- |4.1.0
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-11 20:08
---
Something appears to be going wrong in io/transfer.c. If I compile that file
without optimization, the testcase passes, with optimization it fails. I
suspect it might be an uninitialized variable (ionml?)
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-11 20:12 ---
Subject: Re: interface body has incorrect scope
paulthomas2 at wanadoo dot fr wrote:
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-11
20:02 ---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
20:12 ---
Hmm, the reason why we cannot reproduce it on the mainline is because SRA
thinks the variable a
cannot be SRA'd because we still take the address of the variable even though
that statement is dead.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
20:15 ---
I think adding another DCE pass right before SRA and we will be able to
reproduce this on the mainline
also.
Also note turning off PRE fixes the ICE. It might be PRE moving a statement
causing the
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-11 20:50
---
transfer integer appears to be overwriting the variable ionml when operating
on B edit descriptor. Prior to the function, ionml is NULL, after the
function, the value is 0x31313131.
--
What
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-11 20:53
---
Killed when calling btoa() for conversion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22412
--- Additional Comments From bernie at develer dot com 2005-07-11 21:07
---
A revised patch was posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00853.html
I will attach it here in case someone wants to apply it
to an old version of GCC.
--
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-07-11 21:38 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED
foo.F:
program foo
#include foo.h
end
foo.h:
c This is just a dummy include file for the -*- Fortran -*- preprocessor
% gfortran -c foo.F
Warning: foo.h:3: file foo.F left but not entered
--
Summary: gfortran preprocessing regression: nonsense warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
21:54 ---
Confirmed.
--
What|Removed |Added
CC||jakub at
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-11 21:57
---
btoa() is overwriting the buffer scratch. Although btoa() is in write.c, the
buffer scratch is defined in transfer.c, so optimizing transfer.c changes the
placement of scratch and exposes the failure.
--
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-11 22:02
---
I'm pretty sure the problem is the line
p = scratch + sizeof (SCRATCH_SIZE) - 1;
SCRATCH_SIZE is the size of the buffer. sizeof (SCRATCH_SIZE) probably is not
what the author meant.
--
--- Additional Comments From jakub at redhat dot com 2005-07-11 22:28
---
Oops. Untested patch, will do more testing tomorrow^Wtoday:
2005-07-12 Jakub Jelinek [EMAIL PROTECTED]
PR fortran/22417
* scanner.c (preprocessor_line): Fix file left but not entered
Another one:
PROCEDURE CC1204A IS
BEGIN
DECLARE
TYPE ARR IS ARRAY (natural RANGE ) OF CHARACTER;
TYPE RECD (C : natural := 1) IS
RECORD
C1 : ARR (1..C);
END RECORD;
X1 : RECD;
GENERIC
P2 :
--
What|Removed |Added
BugsThisDependsOn||22418
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
23:10 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-11
23:20 ---
(In reply to comment #0)
Another one:
I think this testcase is the same problem:
PROCEDURE C37213D IS
TYPE MY_ARR IS ARRAY (natural RANGE ) OF INTEGER;
FUNCTION F1 RETURN natural IS
BEGIN
--- Additional Comments From bernie at develer dot com 2005-07-11 23:23
---
Created an attachment (id=9246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9246action=view)
Updated patch
--
What|Removed |Added
--- Additional Comments From bernie at develer dot com 2005-07-11 23:25
---
Patch attached to Bug #18421 (Attachment #9246).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16719
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
23:32 ---
Subject: Bug 16719
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-11 23:32:01
Modified files:
gcc: ChangeLog
gcc/config/m68k:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-11
23:32 ---
Subject: Bug 18421
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-11 23:32:01
Modified files:
gcc: ChangeLog
gcc/config/m68k:
--- Additional Comments From bernie at develer dot com 2005-07-11 23:33
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From bernie at develer dot com 2005-07-11 23:34
---
Fixed on mainline. Pending for 4.0 and 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16719
--- Additional Comments From bernie at develer dot com 2005-07-11 23:35
---
Oops... still pending for 4.0 and 3.4.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-07-11
23:39 ---
I think this means the testsuite needs to be updated, but am not sure how. The
README says:
The check step will proceed to construct a shell script that
will exercize all the fixes, using the
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-07-11
23:40 ---
(On my system, I get seven chunks of 'diff' output, not just this one.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18367
Another case:
with C392014_2;
package body C392014_0 is
function Create return T'Class is
begin
return C392014_2.Create ;
end Create;
end C392014_0;
package C392014_0 is
type T (D : natural) is abstract tagged null record;
function Create return T'Class;
end C392014_0;
--
What|Removed |Added
OtherBugsDependingO||22368
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22419
Another:
PROCEDURE C41304B IS
TYPE V (DISC : INTEGER := 0) IS
RECORD
Y : INTEGER;
END RECORD;
TYPE T IS ACCESS V;
FUNCTION F RETURN V IS
BEGIN
RETURN (DISC = 4, Y = 3);
END F;
BEGIN
null;
END C41304B;
Again see PR 22368
--
What|Removed |Added
BugsThisDependsOn||22420
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-12
00:01 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|NEW
--
Bug 19639 depends on bug 17640, which changed state.
Bug 17640 Summary: empty loop not removed after optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17640
What|Old Value |New Value
1 - 100 of 149 matches
Mail list logo
