https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
Iain Sandoe changed:
What|Removed |Added
Build|i386-pc-solaris2.11 |i386-pc-solaris2.11,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Target: i686-darwin
between - r15-386 and r15-516
not analysed any further yet - but x86_64 bootstrap on the same
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
see also this thread: https://gcc.gnu.org/pipermail/gcc/2024-May/243949.htm
version 0.25 and 0.26 have test cases that require c++17 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #58 from Iain Sandoe ---
As far as I can tell, (at least on targets with TLS support) since the
variables __once_callable and __once_call have a single instance per thread,
the current implementation does not support nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> I happened to do an AIX build on cfarm119 - and looking at this, not sure
> why AIX is failing; although the LTO is handled in a different way in AIX,
> there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #7 from Iain Sandoe ---
I happened to do an AIX build on cfarm119 - and looking at this, not sure why
AIX is failing; although the LTO is handled in a different way in AIX, there
are actually no instances of "ascii" in the assembler
||2024-05-11
CC||iains at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #6 from Iain Sandoe ---
it also fails on Darwin because the LTO section names are different (and
therefore are not being excluded)
-- I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #31 from Iain Sandoe ---
(In reply to Liviu Ionescu from comment #30)
> (In reply to Dimitry Andric from comment #29)
> > ... fixes system.h which is also included by gcov.cc
>
> ok, great.
>
> > Which version of gcc were you
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
The call to __cxa_atexit is elided on Darwin.
The rules for what binds locally on Mach-O might be in error (but I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
: testsuite-fail, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
I found this while working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Pierre-Emmanuel Patry from comment #2)
> While you are at it, it would be useful to add a link to the rust langauge
> specification (like there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
--- Comment #8 from Iain Sandoe ---
A secondary comment - the wiring up of the built-ins that allocate/deallocate
trampoline entries makes the underlying mechanism opaque to the middle end
consumer.
So, although the current example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #26 from Iain Sandoe ---
NOTE: I adjusted the PR lines in the commit header so that the commits get
reflected on the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #11 from Iain Sandoe ---
(In reply to Jason Merrill from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > > So I am actually asking if the extension actually has any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #7 from Iain Sandoe ---
however:
1) it is not in the gnu:: namespace the tests just have it as [[ ]].
2) I do not think that the standard has anything to say about how entities at
file scope are ordered in memory (many/most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #4 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #5 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101718
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #23 from Iain Sandoe ---
(In reply to Gerald Pfeifer from comment #22)
> (In reply to Dimitry Andric from comment #21)
> > Indeed, please merge both commits:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #20 from Iain Sandoe ---
This is fixed on trunk, but is needed on open release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297
--- Comment #3 from Iain Sandoe ---
this seems to have been fixed by r14-6423-g02f562484c1752, does it need back
porting? or should we close?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #10 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #16 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #15)
> (In reply to Peter Bergner from comment #12)
> > (In reply to Sergey Fedorov from comment #11)
> > > (In reply to GCC Commits from comment #10)
> > > > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #7 from Iain Sandoe ---
now that boehm-gc is no longer in tree
what should we do with this?
I suppose there could be some more sophisticated top-level configuration
(similar to GMP et. al.) which determines if there's a suitable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
Bug 42818 depends on bug 41596, which changed state.
Bug 41596 Summary: handling of library-related options by g++spec.c causes a
failure when generating pch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #31 from Iain Sandoe ---
what is the current situation with this
- what input are we waiting for?
- is the problem now cleared for powerpc64-freebsd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590
Iain Sandoe changed:
What|Removed |Added
Build|x86_64-apple-darwin1[5678] |x86_64-apple-darwin1[56789]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #12 from Iain Sandoe ---
what input is this waiting for at the moment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #9 from Iain Sandoe ---
I think this is fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin20 |*-darwin*
Component|testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #5 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> The question is: will this reveal new issues in other tests that weren't
> running before. I'm starting a new regtest and will post the results here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> Jakub has posted a patch in the linker PR (thanks!).
>
> But there remains a darwin bug. The test in check_effective_target_shared
> actually works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #1 from Iain Sandoe ---
note Darwin's linker does not, by default permit symbols to be undefined. If
the test case requires allowing undefined symbols to complete, then either we
need to specify them thus:
-Wl,-U,_XXX (for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #15 from Iain Sandoe ---
(In reply to Dimitry Andric from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > (In reply to Francois-Xavier Coudert from comment #11)
> > > Starting with Xcode 15.3 and the SDK for macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #13 from Iain Sandoe ---
fixed on trunk, intending to backport it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #6 from Iain Sandoe ---
I'm still finding this a bit confusing.
- we have not altered the code in this area (at least not the Darwin parts)
during the gcc-14 cycle.
- apparently, it works with previous Xcode versions/SDKs
- from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #4 from Iain Sandoe ---
Created attachment 57501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57501=edit
without PCH
As Andrew says, the differences are in the debug info (it might even only be in
the order of the debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #3 from Iain Sandoe ---
Created attachment 57500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57500=edit
with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #5 from Iain Sandoe ---
The manual currently says:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched for header
files dur- ing preprocessing. If dir begins with ‘=’ or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #3 from Iain Sandoe ---
so .. if i follow your discussion correctly - neither clang nor gcc finds it
because it's incorrectly quoted (is that an SDK issue?).. or?
We do have control, IIRC, about adding the frameworks search path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #1 from Iain Sandoe ---
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
should be a symlink to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #26 from Iain Sandoe ---
but from your initial post it's also guarded by:
#ifndef __has_cpp_attribute
#define __has_cpp_attribute(x) 0
#endif
so it will always be 0 for clang in C mode, since that does not define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #22 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #21)
> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
> The only issue left (the gcc.dg/framework-1.c failure) so far seems to
> be an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #2)
> This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS
> 14.3).
> I am attaching the preprocessed source.
>
> The code from CFData.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #2 from Iain Sandoe ---
if there are lots of symbols that need to be undefined .. then one can use an
undefined symbols file.
Of course, it does not work if we do not know the symbol names at build-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #1 from Iain Sandoe ---
yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my
guess is that this is an anachronism from the ld_classic (v1) days.
We can tell the linker it's OK for a symbol to be undefined -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #1 from Iain Sandoe ---
let me see if we're adding an extra in the Darwin specs that is covered
elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some
time to sync the ones in darwin.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #1 from Iain Sandoe ---
which actual SDK is this?
you should be able to look at the SDKsettings.plist in the root of the SDK, if
there's any need to discriminate versions with the same name.
(and is it possible to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #7 from Iain Sandoe ---
(In reply to Sebastian "spaetz" Spaeth from comment #5)
> I fully understand that nobody wants to invest time into fixing this. What
> would be nice though, is if this were really just a missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #11 from Iain Sandoe ---
looking at n2176 - C18 there is no mention of __has_c*
looking at n3047 - C23 there is mention only of __has_c_attribute
OTOH, there is no prohibition in declaring __has_cpp_attribute (c.f. an actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #10 from Iain Sandoe ---
indeed, it seems clang does not define __has_cpp_attribute for -std=c11 c
compilations, whereas GCC does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> perhaps this is also a clang regression - for Jakub's example with Xcode
> 15.1 :
(xcode clang, that is, I did not test with upstream clang yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #5 from Iain Sandoe ---
perhaps this is also a clang regression - for Jakub's example with Xcode 15.1 :
$ clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
master-wip-short-queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #9 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Sergey Fedorov from comment #6)
> > (In reply to Andrew Pinski from comment #0)
> > > This is the new bug for PR 19405. Keeping track of that we no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
--- Comment #1 from Iain Sandoe ---
the intent was not to enable this feature for platforms we could not test.
but libgcc/config.host has "aarch64*-*-linux*" so we have inadvertently enabled
it for aarch64-linux-musl.
assuming linux-musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Component|pch |c++
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-02-17
: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-darwin*
somewhere between r14-8885 and r14-9043
FAIL: g++.dg/pch/system-1.C -g assembly comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin21 |x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 105755, which changed state.
Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
What|Removed |Added
|1
CC||iains at gcc dot gnu.org
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |---
--- Comment #7 from Iain Sandoe ---
see comment #5 and #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Component|c++ |other
Keywords|wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
--- Comment #1 from Iain Sandoe ---
the problem is that liberty is using the value set by posix_spawnp for pid.
but:
(darwin):
The argument pid is a pointer to a pid_t variable to receive the pid of
the spawned process; if this is NULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED
Priority: P3
Component: c++
Assignee: iains at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-*-darwin*
Initial analysis: this seems to be hanging in a read in libcody.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #5 from Iain Sandoe ---
AFAICT, this was fixed on trunk by r14-6721-gd31c54c7da7661 (which seems to
have a reference to the PR so not sure why it did not show up here).
I think we need this on any open branch which we want to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many libphobos tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many obj-c++ tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Most gdc|Most gdc tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #4 from Iain Sandoe ---
Created attachment 57378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=edit
patch under test
This implements the common case for an i386 trampoline (and, in this respect,
matches the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #3 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #2)
> Guess an ia32 implementation would be even better, shouldn't be that hard.
I have a draft on one of my machines, I'll post it here tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #1 from Iain Sandoe ---
I was looking at making an i686 impl.
but we could also do as you suggest for gcc-14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #10 from Iain Sandoe ---
automake if is limited to testing a single variable, so we have to introduce an
AM_CONDITIONAL to say the OS is DARWIN (we did not seem to have one already,
but I could have missed something else usable).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #7 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > Maybe:
> >
> > ifneq ($(filter %-darwin%,${host_alias}),)
>
> ${target_os} instead maybe?
I'll give that a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
--- Comment #11 from Iain Sandoe ---
(In reply to Rainer Orth from comment #10)
> Patch posted.
FWIW Darwin is, indeed, also affected and I have patches in progress to resolve
it.
1 - 100 of 2673 matches
Mail list logo
