[Bug c/42046] New: missed optimization on ARM
$ cat test.c
int var;
void foo(int enable)
{
if (enable)
var |= 1;
else
var = ~1;
}
$ arm-elf-gcc.exe -O6 -S test.c
$ cat test.s
.file test.c
.text
.align 2
.global foo
.type foo, %function
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #0
ldrne r3, .L4
ldreq r3, .L4
ldrne r2, [r3, #0]
ldreq r2, [r3, #0]
orrne r2, r2, #1
biceq r2, r2, #1
strne r2, [r3, #0]
streq r2, [r3, #0]
bx lr
.L5:
.align 2
.L4:
.word var
.size foo, .-foo
.comm var,4,4
.ident GCC: (GNU) 4.5.0 20091114 (experimental)
This should be:
cmp r0, #0
ldr r3, .L4
ldr r2, [r3, #0]
orrne r2, r2, #1
biceq r2, r2, #1
str r2, [r3, #0]
bx lr
Interestingly -Os eliminates two of the three duplicates:
ldr r3, .L5
cmp r0, #0
ldrne r2, [r3, #0]
ldreq r2, [r3, #0]
orrne r2, r2, #1
biceq r2, r2, #1
str r2, [r3, #0]
bx lr
Due to inefficient cache use the -Os version will probably execute faster than
-O6.
This is built with svn revision 154184
--
Summary: missed optimization on ARM
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046
[Bug c++/41933] New: internal compiler error: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:5353
$ cat test.c
template typename... TT
struct foo
{
void bar(int i, TT... tt)
{
auto l = [tt...](){};
}
};
void moo()
{
foo foo;
foo.bar(0);
}
$ arm-elf-g++.exe -std=gnu++0x -c test.c
test.c: In member function 'void fooTT::bar(int, TT ...)':
test.c:6:12: error: parameter packs not expanded with '...':
test.c:6:12: note: 'tt'
test.c:6:14: error: expected ',' before '...' token
test.c:6:14: error: expected identifier before '...' token
test.c: In member function 'void fooTT::bar(int, TT ...) [with TT = {}]':
test.c:14:14: instantiated from here
test.c:6:21: error: using invalid field 'fooTT::bar(int, TT
...)::lambda()::__tt'
cc1plus: internal compiler error: tree check: expected field_decl, have
error_mark in build_lambda_object, at cp/semantics.c:5353
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is with svn rev 153796.
--
Summary: internal compiler error: tree check: expected
field_decl, have error_mark in build_lambda_object, at
cp/semantics.c:5353
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
[Bug c++/41934] New: function parameter pack inaccessible inside lambda
$ cat test.c
void foo(...);
template typename... TT
void bar1(TT... tt)
{
auto my_precious = [=](){ foo(tt...); };
}
template typename... TT
void bar2(TT... tt)
{
auto my_precious = [](){ foo(tt...); };
}
$ arm-elf-g++.exe -std=gnu++0x -c test.c
test.c: In lambda function:
test.c:7:35: error: parameter packs not expanded with '...':
test.c:7:35: note: 'tt'
test.c:7:37: error: expansion pattern '((const bar1(TT
...)::lambda()*)this)-bar1(TT ...)::lambda()::tt' contains no argument
packs
test.c: In lambda function:
test.c:14:35: error: parameter packs not expanded with '...':
test.c:14:35: note: 'tt'
test.c:14:37: error: expansion pattern '((const bar2(TT
...)::lambda()*)this)-bar2(TT ...)::lambda()::tt' contains no argument
packs
This is with svn rev 153796.
Bug 41933 could be related to this.
--
Summary: function parameter pack inaccessible inside lambda
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41934
[Bug c++/41933] internal compiler error: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:5353
--- Comment #2 from bruck dot michael at googlemail dot com 2009-11-04 03:15 --- I filed Bug 41934, which may have related causes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
[Bug lto/41902] Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared)
--- Comment #2 from bruck dot michael at googlemail dot com 2009-11-02 11:47 --- (In reply to comment #1) Works for me with both recent libelf and elfutils. The code didn't really change recently, so what libelf do you have installed? libelf-0.8.12 I think I understand what is happening now. libelf's configure finds a valid elf.h in /usr/include that was installed by cygwin. The sys_elf.h switch mechnism is then configured to include that file from cygwin rather than the elf_repl.h provided by libelf. But cygwin's elf.h lacks the SHN_XINDEX macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41902
[Bug c++/41920] New: Invalid 'unused parameter' warning for parameters used in lambdas
$ cat test1.c
int foo(int i)
{
auto bar = [=](){ return i; };
return bar();
}
$ arm-elf-g++.exe -std=gnu++0x -Wall -Wextra -c test1.c
test1.c:1:5: warning: unused parameter 'i'
--
Summary: Invalid 'unused parameter' warning for parameters used
in lambdas
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41920
[Bug lto/41902] New: Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared)
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../sources/gcc-4.5.x/gcc -I../../../sources/gcc-4.5.x/gcc/. -I../../../sources/gcc-4.5.x/gcc/../include -I../../../sources/gcc-4.5.x/gcc/../libcpp/include -I../../../sources/gcc-4.5.x/gcc/../libdecnumber -I../../../sources/gcc-4.5.x/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND -I/cygdrive/c/arm-elf-cy/libelf-0.8.12/include -I/cygdrive/c/arm-elf-cy/libelf-0.8.12/include/libelf ../../../sources/gcc-4.5.x/gcc/c-lang.c -o c-lang.o ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c: In function 'lto_elf_file_close': ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: 'SHN_XINDEX' undeclared (first use in this function) ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: (Each undeclared identifier is reported only once ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: for each function it appears in.) make[2]: *** [lto/lto-elf.o] Error 1 SHN_XINDEX seems to be internal to libelf This is with svn rev 153796. -- Summary: Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruck dot michael at googlemail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: arm-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41902
[Bug c++/38620] New: internal compiler error: in finish_decltype_type
$ cat test.cpp
template typename T
void foo(T x)
{
}
void bar()
{
decltype(fooint) dt;
}
$ g++ -std=gnu++0x -c test.cpp
test2.cpp: In function 'void bar()':
test2.cpp:9: internal compiler error: in finish_decltype_type, at
cp/semantics.c:4193
This fails on mingw 4.3.0 and fresh svn on linux.
--
Summary: internal compiler error: in finish_decltype_type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38620
[Bug c++/38612] New: Vague error diagnostics for pointer-to-member type incompatibility
Consider this example:
--
struct Base {};
struct X; // X derived from Base later but incomplete
here
struct Y {};// Y not derived from Base
int test1(int Base::* p2m, X* object)
{
return object-*p2m;// fails because X is incomplete
}
struct X : Base
{
};
int test2(int Base::* p2m, X* object)
{
return object-*p2m;// OK
}
int test3(int Base::* p2m, Y* object)
{
return object-*p2m;// fails because Y is not derived from A
}
--
produces the following errors:
In function 'int test1(int Base::*, X*)':
error: pointer to member type 'int' incompatible with object type 'X'
In function 'int test3(int Base::*, Y*)':
error: pointer to member type 'int' incompatible with object type 'Y'
The error messages could be made more useful to the user by
a) including the class type of the pointer to member type or the full p2m type
(this might be a bug, depending on whether the programmer's intention was to
actually print that instead of the rather uninteresting pointed-to type)
b) adding to the message for test1 something that points out that X was
incomplete when evaluated.
The code in cp/typeck2.c build_m_component_ref() uses a shortcut here to print
the identical message for two errors that have very different implications from
the user's perspective.
--
Summary: Vague error diagnostics for pointer-to-member type
incompatibility
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruck dot michael at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
--- Comment #1 from bruck dot michael at googlemail dot com 2008-12-23 15:53 --- in the example the last comment should read // fails because Y is not derived from Base instead of // fails because Y is not derived from A -- bruck dot michael at googlemail dot com changed: What|Removed |Added CC||bruck dot michael at ||googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
--- Comment #2 from bruck dot michael at googlemail dot com 2008-12-24 00:48 --- Created an attachment (id=16977) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16977action=view) Broader test case for incomplete base and object types test1 shows the case where the base type is incomplete test2 shows the case where the object type is incomplete test3 shows the case where the object type is incompatible (to which the original error message is taylored) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
--- Comment #3 from bruck dot michael at googlemail dot com 2008-12-24 00:52 --- Created an attachment (id=16978) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16978action=view) proposed patch to gcc/cp/typeck2.c - changes type in error message from type to ptrmem_type as was probably intended originally - adds distinct messages for the two cases where incomplete types were evaluated -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
[Bug libstdc++/38596] New: tr1_impl/functional incompatible with -fno-rtti
tr1_impl/functional uses typeid and fails when used with -fno-rtti It would be more useful if functionality would simply be reduced when -fno-rtti is used with #ifdef __GXX_RTTI used to wrap RTTI code. $ cat testcase.cpp #include functional $ gcc -std=gnu++0x -fno-rtti -c testcase.cpp -- Summary: tr1_impl/functional incompatible with -fno-rtti Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruck dot michael at googlemail dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #2 from bruck dot michael at googlemail dot com 2008-12-21 15:36 --- Basically my thoughts too. But I am not familiar enough with these headers to say that this is side-effect free, especially with all that SFINAE code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #7 from bruck dot michael at googlemail dot com 2008-12-21 16:36 --- Thanks Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
