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).