Explicit specialization after instantiation error

[steveire]

Bugzilla Link	38109
Version	trunk
OS	Windows NT
CC	@dwblaikie,@DougGregor,@jeremyd2019,@mstorsjo,@zygoloid

Extended Description

Clang does not accept code which CL.exe accepts. The example works if I remove the dllexport.

C:\dev\src\playground\cpp>C:\dev\src\llvm\build\releaseprefix\msbuild-bin\cl.exe explicit_instantiation.cpp
explicit_instantiation.cpp
explicit_instantiation.cpp(12,21):  error: explicit specialization of 's_foo' after instantiation
template<> B* A<B>::s_foo = nullptr;
                    ^
explicit_instantiation.cpp(5,15):  note: implicit instantiation first required here
    static T* s_foo;
              ^
1 error generated.

C:\dev\src\playground\cpp>cl.exe explicit_instantiation.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26430 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

explicit_instantiation.cpp
Microsoft (R) Incremental Linker Version 14.14.26430.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:explicit_instantiation.exe
explicit_instantiation.obj
   Creating library explicit_instantiation.lib and object explicit_instantiation.exp

C:\dev\src\playground\cpp>type explicit_instantiation.cpp

template <typename T>
class A
{
    static T* s_foo;
};

class __declspec(dllexport) B : public A<B>
{
};

template<> B* A<B>::s_foo = nullptr;

int main()
{
    return 0;
}

[llvmbot]

Even simpler example:

 template <typename T>
 class __declspec(dllexport) A {
  public:
   static const T foo;
 };

 template <>
 const int A<int>::foo = 42;

Leads to:

 (...) error: explicit specialization of 'foo' after instantiation
 const int A<int>::foo = 42;
                   ^

 (...) note: implicit instantiation first required here
   static const T foo;
                  ^

I'm curious to know where the implicit instantiation comes from, and with which template parameter.

[jeremyd2019]

Ran into this trying to build kirigami for x86_64-w64-windows-gnu using Clang 12.0.1. GCC also accepts this construct.

https://invent.kde.org/frameworks/kirigami/-/blob/master/src/libkirigami/platformtheme.h#L370

https://invent.kde.org/frameworks/kirigami/-/blob/master/src/libkirigami/platformtheme.cpp#L30

[jeremyd2019]

I ran into a Microsoft document that says

The problem with a specialization of a class template is where to place
the __declspec(dllexport); you are not allowed to mark the class template.
Instead, explicitly instantiate the class template and mark this explicit
instantiation with dllexport. For example:

template class __declspec(dllexport) B;

I tried that, but that gave a warning: 'dllexport' attribute ignored on explicit instantiation definition [-Wignored-attributes].

But from the initial report, I guess the doc was mistaken (or out of date) and you are allowed to mark the class template with dllexport.

[mstorsjo]

Ran into this trying to build kirigami for x86_64-w64-windows-gnu using
Clang 12.0.1. GCC also accepts this construct.

Do note that there are lots of subtle differences between GCC and MSVC about where you should specify dllexport with respect to e.g. extern templates.

This is e.g. how it's done with respect to exporting full template instantiations:

template <typename T> class A {
public:
  T add(T input) { return input + input; }
};

#ifdef _MSC_VER
// Header
extern template class A<int>;
// Implementation file
template class __declspec(dllexport) A<int>;
#else
// Header
extern template class __declspec(dllexport) A<int>;
// Implementation file
template class A<int>;
#endif

Also have a look at libcxx's config file which maps the dllexport/import attributes to different locations depending on configuration (dllexport/dllimport, and MSVC vs MinGW):

https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0-rc1/libcxx/include/__config#L613-L655
(in particular, lines 629-635)

In general, libcxx doesn't set dllexport on a template declaration because this causes the template to be instantiated (_LIBCPP_TEMPLATE_VIS is defined to an empty string).

With the example shown earlier here, this form seems to work on both MSVC, GCC and Clang in both modes:

template <typename T>
 class A {
  public:
   static const __declspec(dllexport) T foo;
};

template<> const int __declspec(dllexport) A<int>::foo = 42;

With GCC, this produces the same type of exports as the original example. With MSVC, the original example (with dllexport on the template class itslef) it also ends up dllexporting two instantiations of 'operator=()'.

[jeremyd2019]

With the example shown earlier here, this form seems to work on both MSVC,
GCC and Clang in both modes:

template
class A {
public:
static const __declspec(dllexport) T foo;
};

template<> const int __declspec(dllexport) A::foo = 42;

With GCC, this produces the same type of exports as the original example.
With MSVC, the original example (with dllexport on the template class
itslef) it also ends up dllexporting two instantiations of 'operator=()'.

Yes, that is also what we came up with msys2/MINGW-packages#7589 (reply in thread)

But, in the real-world example of Kirigami2 (rather than a minimal reproducer), it results in different exports than what GCC made with the dllexport on the template class: it is not exporting the destructor (the base class has a virtual destructor, and the class itself has some non-trivial members), the vtable, or the typeinfo for the instantiations for which the static member is specialized. I could not find a way to export those with Clang.

[jeremyd2019]

But, in the real-world example of Kirigami2 (rather than a minimal
reproducer), it results in different exports than what GCC made with the
dllexport on the template class: it is not exporting the destructor (the
base class has a virtual destructor, and the class itself has some
non-trivial members), the vtable, or the typeinfo for the instantiations for
which the static member is specialized. I could not find a way to export
those with Clang.

This doesn't seem to really affect kirigami2 however. Making that change doesn't seem to have changed the symbols exported by GCC, only that the symbols exported by Clang differ from those exported by GCC.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Stephen Kelly (steveire)

| | | | --- | --- | | Bugzilla Link | [38109](https://llvm.org/bz38109) | | Version | trunk | | OS | Windows NT | | CC | @dwblaikie,@DougGregor,@jeremyd2019,@mstorsjo,@zygoloid |

Extended Description

Clang does not accept code which CL.exe accepts. The example works if I remove the dllexport.

C:\dev\src\playground\cpp>C:\dev\src\llvm\build\releaseprefix\msbuild-bin\cl.exe explicit_instantiation.cpp
explicit_instantiation.cpp
explicit_instantiation.cpp(12,21):  error: explicit specialization of 's_foo' after instantiation
template<> B* A<B>::s_foo = nullptr;
                    ^
explicit_instantiation.cpp(5,15):  note: implicit instantiation first required here
    static T* s_foo;
              ^
1 error generated.

C:\dev\src\playground\cpp>cl.exe explicit_instantiation.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26430 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

explicit_instantiation.cpp
Microsoft (R) Incremental Linker Version 14.14.26430.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:explicit_instantiation.exe
explicit_instantiation.obj
   Creating library explicit_instantiation.lib and object explicit_instantiation.exp

C:\dev\src\playground\cpp>type explicit_instantiation.cpp

template <typename T>
class A
{
    static T* s_foo;
};

class __declspec(dllexport) B : public A<B>
{
};

template<> B* A<B>::s_foo = nullptr;

int main()
{
    return 0;
}

[tfpf]

I think this bug has nothing to do with dllexport! Here's a simpler way to replicate it.

header.hh

#ifndef HEADER_HH_
#define HEADER_HH_

template<typename T>
struct Foo
{
    T foo(void);
};

extern template struct Foo<int>;

#endif

source.cc

#include "header.hh"

template struct Foo<int>;

template<>
int Foo<int>::foo(void)
{
    return -1;
}

main.cc

#include <iostream>

#include "header.hh"

int main(void)
{
    std::cout << Foo<int>().foo() << '\n';
}

Command Line

$ g++ -Wall -Wextra main.cc source.cc && ./a.out 
-1

$ clang++ -Wall -Wextra main.cc source.cc && ./a.out 
source.cc:6:15: error: explicit specialization of 'foo' after instantiation
    6 | int Foo<int>::foo(void)
      |               ^
./header.hh:10:24: note: explicit instantiation first required here
   10 | extern template struct Foo<int>;
      |                        ^
1 error generated.

GCC is happy with this code, but Clang isn't.

$ g++ --version
g++ (GCC) 15.2.1 20250813
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang++ --version
clang version 20.1.8
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin