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)
commitc06a470fc84352642e670a0159bb4846f5aa2a3c
treeca29c8226ec36642249d3a190353030978f6fc96
parent65a422c81c99a616f4b2eb502108907460265f51
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.

llvm-svn: 359135
llvm/include/llvm/Support/ManagedStatic.h
llvm/lib/Support/CommandLine.cpp