#345 duplicate section has different size warning with virtual functions, namespaces and -Os

v1.0 (example)
open
nobody
None
5
2015-02-12
2013-09-14
Nicholas
No

Consider the following three files:

1) osrng.cpp

#include "osrng.h"

void CryptoPP::RandomNumberGenerator::GenerateBlock() // required
{
}

void AutoSeededRandomPool::Reseed() // optional
{
}

2) osrng.h

namespace CryptoPP { // must be in a namespace

class RandomNumberGenerator
{
public:
    virtual void GenerateBlock(); // required
};

}

class AutoSeededRandomPool : public CryptoPP::RandomNumberGenerator // must be inherited
{
public:
    AutoSeededRandomPool()
    {
        // one of these suffices
        GenerateBlock();
        Reseed();
    }
    void Reseed(); // optional
};

3) test.cpp

#include "osrng.h"

int main() {
    AutoSeededRandomPool rnd;
}

If I first compile osrng.cpp with g++ -c osrng.cpp, then do g++ test.cpp osrng.o -Os, I get the following warning:

osrng.o: duplicate section `.rdata$_ZTSN8CryptoPP21RandomNumberGeneratorE[__ZTSN8CryptoPP21RandomNumberGeneratorE]' has different size

I'm not sure what exactly is causing this warning, but here are a few observations:

1) The warning disappears if both files are compiled with the same optimization.
2) AutoSeededRandomPool must inherit a namespaced class with a virtual function defined in a separate file. If any of these aren't satisfied, then the warning disappears.
3) AutoSeededRandomPool's constructor must call either its own member function or the inherited class's function (or both), otherwise no warning.
4) The constructor must be defined inline.

One might argue that a single warning in such an edge case shouldn't matter. However, when I compile my own project against Crypto++ with -Os, I get about 200 such warnings, which is pretty damn annoying. It took me a couple of days to reduce Crypto++ to this minimal test case, so I hope someone looks into this issue.

gcc version 4.8.1, but I had the same problem on previous versions too. No warnings on Linux at all, so I assume it's a MinGW bug.

Discussion