[Bug c++/55670] New: This isn't a pure virtual method.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55670
Bug #: 55670
Summary: This isn't a pure virtual method.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qufa...@gmail.com
Target: x86_64-linux-gnu
Build: gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-11precise2)
Created attachment 28944
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28944
Preprocessed contents of fptest2.cpp
I've been enjoying the new C++11 features in 4.7. But the combination of
template aliases and non-static data member initialization seems to have caught
a corner-case of pure virtual method parsing.
CONTENTS OF fptest.cpp
template using F = T;
struct X {
F* fp = nullptr;
};
int main () { return 0; }
I expected this to compile without error, but instead I got:
OUTPUT OF g++-4.7 -std=c++11 fptest.cpp
fptest.cpp:3:29: error: invalid pure specifier (only ‘= 0’ is allowed) before
‘;’ token
=
It compiles if I set fp to nullptr in a constructor, and it compiles if I
declare fp with traditional function pointer syntax, " void (* fp ) ()". It
gives the same error if I initialize fp to the address of a function instead of
nullptr.
Just for kicks, I decided to see what would happen if I tried to initialize fp
to 0.
OUTPUT OF g++-4.7 -std=c++11 fptest2.cpp
fptest2.cpp:4:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccjdsX7p.out file, please attach this to
your bugreport.
==
Oh. Well then.
OUTPUT OF g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-11precise2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-11precise2)
==
[Bug c++/55680] New: [C++11] Member specialization with lambda is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55680
Bug #: 55680
Summary: [C++11] Member specialization with lambda is rejected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qufa...@gmail.com
CONTENTS OF speclambda.cpp
template struct X {
static void (* code ) ();
};
template <> void (* X::code ) () = [](){};
int main () { return 0; }
OUTPUT OF g++-4.7 -std=c++11
speclambda.cpp:4:42: error: explicit specialization of non-template ‘’
==
It succeeds if I specialize the whole struct instead of just the one member.
The same error occurs if the type of 'code' is std::function.
The same error occurs during any kind of static member specialization whose
initializer contains a lambda (such as an initializer that calls a constructor
with a lambda as an argument).
I'm not 100% certain this is valid code, but even if it is invalid, the error
message is quite misleading.
OUTPUT OF g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-11precise2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-11precise2)
==
[Bug c++/110492] New: Attempted optimization of switch statement pessimizes it instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110492 Bug ID: 110492 Summary: Attempted optimization of switch statement pessimizes it instead Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: qufanat at gmail dot com Target Milestone: --- This happens on my local GCC 11.3, but you can also see it on 13.1 at this godbolt link https://godbolt.org/z/G3qecWxPr I'm creating a switch statement of hashed strings, which compiles to a binary search on the hashes, all well and good. However, with -O3 specified, GCC peels back the last multiplication of the hash for some of the comparison branches, but is unable to do it for others, resulting in longer assembly with twice as many comparisons as is necessary. Here is lines 15..19 in get_choice_1() (end of the hash loop) imulesi, eax, 16777619 testdl, dl jne .L3 (start of the switch) cmp eax, 1954414351 je .L8 cmp esi, 1901626525 ja .L4 eax is the hash without the last imul, and esi is the final hash. If we prevent inlining of the hash function, the compiler can't make this "optimization" and gives the assembly I expect. Here is lines 90..93 in get_choice_2() callhash32_noinline(char const*) cmp eax, 1901626525 je .L33 jbe .L46 Now it only does one comparison per entry and uses it for both the == and <= branches. This isn't that important to my program but I thought you'd like to know.
