[llvm-dev] Problem with mingw32 DLL build

[Chandler Carruth via llvm-dev]

Folks, there is an issue pretty buried in the commits list that I suspect
should have wider visibility.

See r262188 and subsequent discussion. To summarize: it appears that
mingw32 was unable to correctly produce a static data member when
instantiated as a base class. The "fix" is to then explicitly instantiate
the base class separately from its use in a base class.

I think this is unacceptable in this case because these base classes are
intended to be the primary way that users of LLVM will define new analysis
passes. That means we'll actually have to teach LLVM library users about
this pattern, not just the LLVM developers. =/

So my questions are:

1) Is there some more elegant way to fix this that doesn't require every
derived class to write an explicit instantiation definition of their base
class? If so, then the rest of my questions are moot.

2) If not, is this a problem with a native Windows 32-bit DLL build?

3) If this is a problem with the native Windows 32-bit DLL build, should we
back out of using this pattern of CRTP injection of the static data member
and just deal with the significant (and error prone) boiler plate? It seems
less error prone than the alternative.

4) If this is not a problem with the native Windows 32-bit DLL, then I
wonder how valuable it is to continue to support the conjunction of mingw32
and a DLL build? This seems to be a really high cost to carry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/6a5e4c0d/attachment.html>