https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69210
Bug ID: 69210
Summary: False positives from -Wsuggest-final-types/methods
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
In GCC 5.3 -Wsuggest-final-{types,methods} seems a little trigger happy. For
example this code:
$ cat final.cpp
// in a header...
class A
{
public:
virtual ~A() {}
virtual int f(int x) { return 2*x; }
virtual int g(int x) = 0;
};
// later in a source file...
int foo(A& a, int x)
{
return a.f(a.g(x));
}
$ g++ -O3 -std=c++11 -c -Wall -Wextra -Wsuggest-final-types
-Wsuggest-final-methods final.cpp
final.cpp:3:7: warning: Declaring type 'class A' final would enable
devirtualization of 1 call [-Wsuggest-final-types]
class A
^
final.cpp:7:19: warning: Declaring method 'virtual int A::f(int)' final would
enable devirtualization of 1 call [-Wsuggest-final-methods]
virtual int f(int x) { return 2*x; }
$ g++ -v
Using built-in specs.
COLLECT_GCC=/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)
But I think it doesn't make sense to warn that a type should be final, when the
type is directly introducing the new virtual call that could be devirtualized:
if it made sense for A or A::f to be final it would be more reasonable to
remove the virtual keyword entirely. In fact here A can't even be instantiated
due to the pure virtual g(), and thus must be overridden, but gcc seems to miss
that.
This comes up whenever a base type A defines a virtual function with a default
and GCC sees A& being used, without any subclasses of A being visible at the
call.
I have no idea how complicated this would be to fix or if there is any interest
in doing so. I'd be willing to try my hand at a patch, if there is any chance
it would be accepted (if so, any pointers on how/where to proceed would be
great as I'm not that familiar with the gcc sources).
