Re: Explicit instantiation and static objects in different modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4 August 2015 at 17:52, Alexander Monakov wrote:
> On Tue, 4 Aug 2015, Jonathan Wakely wrote:
>
>> On 4 August 2015 at 16:00, Nikolay Vorobyov wrote:
>> > Is this a gcc's bug?
>>
>> I believe this is due to how symbol resolution works in DLLs on
>> Windows, where each DLL has its own copy of the static variable. I
>> don't know how to make it work as required by the C++ standard.
>
> One way would be to eliminate the inline definition of getInstance() in the
> header file, and move it into inst.cpp.
>
> If you inspect generated files with 'nm -C', you'll see that both libinst.dll
> and liba.dll have a definition for StaticObject<int>::getInstance()::t.
>
> Jonathan, I think there might be a GCC bug here, but not what Nikolay
> originally meant.  With -std=c++11, 'extern template' should prevent the
> compiler from instantiating methods of StaticObject, but it doesn't happen.
> Here's a minimal example:
>
> template<int V>
> struct S {
> static int bar()
> {
>   return V;
> }
> };
>
> extern template struct S<42>;
>
> int foo()
> {
>   return S<42>::bar();
> }
>
> Compile with g++ -std=c++11 -S -o- -Os and observe that 'foo' is optimized to
> 'return 42', although 'bar' should not have been instantiated.  If you don't
> have a template class and make 'bar' itself a template function, GCC does not
> optimize 'foo', as expected.  WDYT?

The extern template tells the compiler it doesn't *need* to
instantiate the template, because it will be explicitly instantiated
in another translation unit. But that doesn't mean it *must not*
instantiate it. The compiler can choose to inline the function and in
that case it will implicitly instantiate it. That should be
unobservable because the One Definition Rule means that the implicitly
instantiated definition that gets inlined and the explicitly
instantiation definition in the other translation unit must be
identical. The Windows linkage model seems to break that assumption
... so I don't know what the right behaviour is.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux