llvm-project/clang/test/SemaCXX/PR19955.cpp

// RUN: %clang_cc1 -triple i686-win32 -verify -std=c++11 %s
// RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s

extern int __attribute__((dllimport)) var;
constexpr int *varp = &var; // expected-error {{must be initialized by a constant expression}}

extern __attribute__((dllimport)) void fun();
constexpr void (*funp)(void) = &fun; // expected-error {{must be initialized by a constant expression}}

template <void (*)()>
struct S {};
S<&fun> x;

template <int *>
struct U {};
U<&var> y;
Sema: Allow dllimport entities in template args for mingw Previously dllimport variables inside of template arguments relied on not using the C++11 codepath when -fms-compatibility was set. While this allowed us to achieve compatibility with MSVC, it did so at the expense of MingW. Instead, try to use the DeclRefExpr we dig out of the template argument. If it has the dllimport attribute, accept it and skip the C++11 null-pointer check. llvm-svn: 211766 2014-06-26 07:48:46 +00:00			`// RUN: %clang_cc1 -triple i686-win32 -verify -std=c++11 %s`
			`// RUN: %clang_cc1 -triple i686-mingw32 -verify -std=c++11 %s`
AST: Address of dllimport variables isn't constant The address of dllimport variables isn't something that can be meaningfully used in a constexpr context and isn't suitable for evaluation at load-time. They require loads from memory to properly evaluate. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4250 llvm-svn: 211568 2014-06-24 05:59:13 +00:00
AST: Address of dllimport functions isn't constant The address of dllimport functions can be accessed one of two ways: - Through the IAT which is symbolically referred to with a symbol starting with __imp_. - Via the wrapper-function which ends up calling through the __imp_ symbol. The problem with using the wrapper-function is that it's address will not compare as equal in all translation units. Specifically, it will compare unequally with the translation unit which defines the function. This fixes PR19955. llvm-svn: 211570 2014-06-24 06:40:51 +00:00			`extern int __attribute__((dllimport)) var;`
			`constexpr int *varp = &var; // expected-error {{must be initialized by a constant expression}}`

			`extern __attribute__((dllimport)) void fun();`
			`constexpr void (*funp)(void) = &fun; // expected-error {{must be initialized by a constant expression}}`
AST: Initialization with dllimport functions in C The C++ language requires that the address of a function be the same across all translation units. To make __declspec(dllimport) useful, this means that a dllimported function must also obey this rule. MSVC implements this by dynamically querying the import address table located in the linked executable. This means that the address of such a function in C++ is not constant (which violates other rules). However, the C language has no notion of ODR nor does it permit dynamic initialization whatsoever. This requires implementations to _not_ dynamically query the import address table and instead utilize a wrapper function that will be synthesized by the linker which will eventually query the import address table. The effect this has is, to say the least, perplexing. Consider the following C program: __declspec(dllimport) void f(void); typedef void (*fp)(void); static const fp var = &f; const fp fun() { return &f; } int main() { return fun() == var; } MSVC will statically initialize "var" with the address of the wrapper function and "fun" returns the address of the actual imported function. This means that "main" will return false! Note that LLVM's optimizers are strong enough to figure out that "main" should return true. However, this result is dependent on having optimizations enabled! N.B. This change also permits the usage of dllimport declarators inside of template arguments; they are sufficiently constant for such a purpose. Add tests to make sure we don't regress here. llvm-svn: 211677 2014-06-25 08:15:07 +00:00
			`template <void (*)()>`
			`struct S {};`
			`S<&fun> x;`

			`template <int *>`
			`struct U {};`
			`U<&var> y;`