http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702
--- Comment #1 from Jakub Jelinek ---
Another example:
unsigned int foo (unsigned int x, unsigned int y)
{
x += y;
x += y;
x += y;
x += y;
x += y;
return x;
}
Seems for the x += 7 * y; x += 12 * y; case it is undistribute_ops_list tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57705
Bug ID: 57705
Summary: Non-constant step induction vars not vectorized
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Richard Biener changed:
What|Removed |Added
Known to work||4.9.0
--- Comment #5 from Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Allan McRae from comment #15)
>
> I tried with -include foo.h and a breakpoint in push_command_line_include...
> I just stepped through from that breakpoint and saw cpp_push_default_includ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #2 from Jonathan Wakely ---
Paolo already patched libstdc++ and there's nothing to fix in eCos.
The point is that if I write
extern "C" {
void f();
}
in a libstdc++ header it should mean what the C++ standard says it means.
The imp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57704
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
--- Comment #4 from Paolo Carlini ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01352.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
--- Comment #2 from Paolo Carlini ---
Created attachment 30357
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30357&action=edit
An extended set of tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579
Bug 45579 depends on bug 43665, which changed state.
Bug 43665 Summary: INTENT(IN) etc. optimization of calls: function annotations
for noclobber/noescape arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44589
Bug 44589 depends on bug 43665, which changed state.
Bug 43665 Summary: INTENT(IN) etc. optimization of calls: function annotations
for noclobber/noescape arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697
--- Comment #6 from Dominique d'Humieres ---
Per
> TYPE_QUAL_RESTRICT is now supported, see
> http://gcc.gnu.org/ml/fortran/2009-08/msg00208.html
> TYPE_QUAL_CONST is to my knowledge a no op, for QUAL_VOLATILE,
> I have not checked whether it i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
Bug 24546 depends on bug 29697, which changed state.
Bug 29697 Summary: gfortran should use TYPE_QUAL_CONST etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
Dominique d'Humieres changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Domini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
--- Comment #2 from Dominique d'Humieres ---
Still no warning at revision 200371.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50331
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
Bug 24546 depends on bug 23280, which changed state.
Bug 23280 Summary: gfortran does not emit DW_AT_entry_point (dwarf-2) debugging
info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #2 from Markus Trippelsdorf ---
Here's a reduced example:
% cat test.ii
typedef bool (*IsAcceptableThis) (const int &);
inline int
fn1 (IsAcceptableThis p1)
{
p1 (0);
return 0;
}
__attribute__ ((always_inline))
inline bool f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 40920, which changed state.
Bug 40920 Summary: Derived type with BIND(C) - rejected as argument.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42651
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
Dominique d'Humieres changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #15 from Domin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57706
Bug ID: 57706
Summary: LRA is bottleneck while compiling LTO firefox
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57705
--- Comment #1 from Jakub Jelinek ---
Created attachment 30358
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30358&action=edit
gcc49-pr57705.patch
Patch I'm bootstrapping/regtesting right now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #3 from Jan Hubicka ---
Hmm,
the problem here is that we output errors after early inlining always now,
while previously we did
only when some other inlining happened in the function (adding extra early
inlinable function
to the testca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #29 from Martin Jambor ---
(In reply to Martin Liška from comment #28)
> Patch solved the problem for chromium ;) I will test libreoffice tomorrow.
Great, I have submitted the patch to the mailing list then:
http://gcc.gnu.org/ml/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #17 from Allan McRae ---
Created attachment 30359
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30359&action=edit
gdb log when using -include
When using -include instead of -imacros, the trail is:
LC_ENTER foo.c
LC_RENAME
L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #10 from Bernd Edlinger ---
incredibly...
gcc 4.3.7 was the last version that did only write 5 bytes in foo().
starting with gcc 4.4 all variants read/write 8 bytes in foo().
that applies only to the arm code.
the x86 code does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
Bug ID: 57707
Summary: gcc misinterprets hex escapes in constant strings
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
Bug ID: 57708
Summary: function clobbers callee saved register on ARM
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
--- Comment #2 from duncan_roe at acslink dot net.au ---
I can see it is doing that. Where does the standard say that is correct
behavior?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
CC||mikulas at artax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Domini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 30362
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30362&action=edit
another reproduction code
The code in the first attachment actually did some out-of-memo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
duncan_roe at acslink dot net.au changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Re
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-unknown-linux-gnu
class C {
int both_var;
void var_and_method() {}
void m() { int both_var, var_and_method; }
};
FAIL: gcc (GCC) 4.8.2 20130625 (prerelease)
FAIL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
--- Comment #1 from Andrew Pinski ---
> clang does no warn on "var_and_method" as variable vs. method are safe, if one
> tries to use them inappropriately one gets an error.
Not always. Think of function pointers or pointer to member functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
--- Comment #3 from Jan Kratochvil ---
It may not be exactly correct but from a practical standpoint clang has caught
my bug while not annoying me with tons of needless changes like gcc did, FYI.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Jason Merrill changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #5 from Jason Mer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
Bug ID: 57710
Summary: [OOP] _vptr not set for allocatable CLASS components
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, wrong-code
Severit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
--- Comment #6 from Dominique d'Humieres ---
>From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962#c20
Transformational intrinsics, done are:
* all, any, count
* product, sum
* dot_product, matmul, transpose
* pack, unpack, spread
Left:
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
Dominique d'Humieres changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
Bug 25104 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392
Bug 31392 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31393
Bug 31393 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32890
Bug 32890 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37212
Bug 37212 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
Bug 38205 depends on bug 29962, which changed state.
Bug 29962 Summary: Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392
Bug 31392 depends on bug 25104, which changed state.
Bug 25104 Summary: [F2003] Non-initialization expr. as case-selector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
Dominique d'Humieres changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 25104, which changed state.
Bug 25104 Summary: [F2003] Non-initialization expr. as case-selector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
--- Comment #6 from Dominique d'Humieres ---
> However, one should go through the lengthy, convoluted thread at
>
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/
>to check whether it contains some still-un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
Bug ID: 57711
Summary: Fortran 4.7.2/4.8.1 error: constraints for functions
parameters
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #18 from Manuel Lóp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
--- Comment #2 from Dominique d'Humieres ---
As for 4.8.1 and trunk (r200371), only the second test in comment #0 gives the
'ppr@' name:
real g ! "cannot have a type"
1
Error: Symbol 'ppr@' at (1) cannot have a type
The first test do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57712
Bug ID: 57712
Summary: GCC fails to to match out-of-line template member
function definition with declaration
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jason Merrill from comment #5)
>
> That would be fine. But it seems less important for member functions, since
> there's much less chance of a local variable name conflicting with some
> r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #43 from Domin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #16 from
erived gets the ability to call bar() only inside of the template function
foo.
Happens on (4.9.0 20130625 (experimental)) and (4.8.1).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535
--- Comment #3 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #2)
> I can reproduce it with gfortran 4.7.3 and '-O2
> -ffpe-trap=zero,overflow,invalid -finit-real=snan -mfpmath=387', but not
> with 4.8.1 nor trunk. Could thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #13 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779
Dâniel Fraga changed:
What|Removed |Added
CC||fragabr at gmail dot com
--- Comment #3 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
--- Comment #7 from Vittorio Zecca ---
It looks like it was fixed in 4.7.0 with the following error message
Error: NULL intrinsic at (1) in data transfer statement requires MOLD=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535
--- Comment #4 from Dominique d'Humieres ---
> As the status "accidentally fixed in 4.8 but do not know when and why"
> does not exist, you may well do that.
I get the SIGFPE with revision 192891 (2012-10-28) and 'In p_h_usstd!' with
revision 193
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535
Harald Anlauf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57713
Shane changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Bug ID: 57714
Summary: Newline rendered incorrectly in output
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocesso
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #2 from David Krauss ---
Andrew, are you sure? The zero should remain on the same line as the "return"
token.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #3 from David Krauss ---
See section 9 of the manual:
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Preprocessor-Output.html#Preprocessor-Output
The output from the C preprocessor looks much like the input, except that all
preprocessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
--- Comment #6 from Steve Ellcey ---
The patch in comment #3 worked for me as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715
Bug ID: 57715
Summary: lto1.exe: internal compiler error: in
add_symbol_to_partition
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55587
--- Comment #7 from Andrew Pinski ---
This patch is broken for testing the already installed GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
Dominique d'Humieres changed:
What|Removed |Added
Target|x86_64-apple-darwin10 |x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716
Bug ID: 57716
Summary: std::thread does not compile with vector& as
argument
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716
felix-gcc at fefe dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
duncan_roe at acslink dot net.au changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
duncan_roe at acslink dot net.au changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #5 from David Krauss ---
What? That makes even less sense. Are you guys familiar with the concept of
line splicing? See "phases of translation" in the Standard, namely phase 2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #6 from David Krauss ---
Just to clarify the last comments, the input
main(){\
return 0;
}
translates via cpp to
main(){
return 0;
}
i.e. no splicing is apparent in the output.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #7 from David Krauss ---
Oh, OK, now I followed that link. Splicing is supposed to be transparent unless
you specify -P. This still qualifies as a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #8 from David Krauss ---
Probably what happened:
1. In preserving visual appearance, tokens not separated by spaces are kept
together.
2. Line splicing happens before spaces are identified for the above.
3. The { and return tokens are
1 - 100 of 109 matches
Mail list logo
