]> granicus.if.org Git - llvm/commit
Try once more to ensure constant initializaton of ManagedStatics
authorReid Kleckner <rnk@google.com>
Wed, 24 Apr 2019 20:13:23 +0000 (20:13 +0000)
committerReid Kleckner <rnk@google.com>
Wed, 24 Apr 2019 20:13:23 +0000 (20:13 +0000)
commit3b06e633b7c97ed8fb68877ae2e96c21dd820f84
tree6a6353ad77fc11422d2ff23b2bd74b55cf00047e
parenta67600cb79c8ad9f4e979df9c4cffe7fd12a00b3
Try once more to ensure constant initializaton of ManagedStatics

First, use the old style of linker initialization for MSVC 2019 in
addition to 2017. MSVC 2019 emits a dynamic initializer for
ManagedStatic when compiled in debug mode, and according to zturner,
also sometimes in release mode. I wasn't able to reproduce that, but it
seems best to stick with the old code that works.

When clang is using the MSVC STL, we have to give ManagedStatic a
constexpr constructor that fully zero initializes all fields, otherwise
it emits a dynamic initializer. The MSVC STL implementation of
std::atomic has a non-trivial (but constexpr) default constructor that
zero initializes the atomic value. Because one of the fields has a
non-trivial constructor, ManagedStatic ends up with a non-trivial ctor.
The ctor is not constexpr, so clang ends up emitting a dynamic
initializer, even though it simply does zero initialization. To make it
constexpr, we must initialize all fields of the ManagedStatic.

However, while the constructor that takes a pointer is marked constexpr,
clang says it does not evaluate to a constant because it contains a cast
from a pointer to an integer. I filed this as:
https://developercommunity.visualstudio.com/content/problem/545566/stdatomic-value-constructor-is-not-actually-conste.html

Once we do that, we can add back the
LLVM_REQUIRE_CONSTANT_INITIALIZATION marker, and so far as I'm aware it
compiles successfully on all supported targets.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359135 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Support/ManagedStatic.h
lib/Support/CommandLine.cpp