Intel C++ compiler and Wnon-virtual-dtor flag gives (wrong?) warning

Question

I was trying to compile some code of mine which, in g++ (with the --Wnon-virtual-dtor Flag) compiled just fine. Also, my IDE and clang-tidy didn't warn me (I see that this might be false of course).

When I tried to compile the same code with Intel's icpc (actually this one icpc (ICC) 19.1.2.254 20200623) I got a warning which I was now able to track down - I'm wondering whether I'm somehow at fault or whether that warning is actually not correct in my case.

I wrote a somewhat minimal example of my class hierarchy:

template<typename T>
class B {
        public:
                B() = default;
                virtual ~B() = default;
};

template<typename T>
class C : public B<T> {
        public:
                C() = default;
                ~C() override = default;

                virtual int foo() { return 0; };
};

template<typename T>
class D : public C<T> {
        public:
                D() = default;
                ~D() override = default;
                int foo() override { return 1; };
};


int main() {
        return 0;
}

When compiling this with icpc -Wnon-virtual-dtor foo.cpp I get the following warning:

foo.cpp(15): warning #2026: Effective C++ Item 14 Make sure base classes C have virtual destructors
  };
   ^

One can get rid of that by explicitly stating that the destructor in C is virtual (so virtual ~C() override = default;).

Note, that also getting rid of the template lets the code compile without any warning.

For last - also getting rid of the foo member function will let the code compile without warning.

So yeah - my question is: is this a "bug" in icpc or did I do something wrong?

I was quite unable to find anything useful on that warning #2026 really.

Thanks in advance, Flusslauf

Answer 1

Ok, so after also posting this question on the Intel forum - seems to be (a very much non critical) bug in the compiler - the workaround would be writing both, virtual and override.

This is discouraged by the item C.128 in the cpp core guidelines (same link as in the comments) but not problematic.