Constexpr not supported with __declspec(dllimport).

[zahiraam]

Summary

Fix for issue https://github.com/llvm/llvm-project/issues/53182

[majnemer]

I have a question regarding how this work with respect to the dllimport semantics known by the linker.
IIUC, we will now allow a program like:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {
    return dll_import_constexpr_ref;
}

Here, get will load dll_import_constexpr_ref. However, what will dll_import_constexpr_ref hold? It ought to hold the contents of __imp_?dll_import_int@@3HA. However, we can't dereference __imp_?dll_import_int@@3HA to get to its contents.

[majnemer]

clang/lib/AST/ExprConstant.cpp

2217

The summary and the bug both mention dllimport but this is examining dllexport. Is this intended? If so, please update the comment above this if-statement.

[majnemer]

clang/test/CodeGenCXX/dllimport.cpp

2

Why did this check-prefix change to MSC64? There is already a unique prefix for this RUN line: M64.

[zahiraam]

In D117569#3257121, @majnemer wrote:

I have a question regarding how this work with respect to the dllimport semantics known by the linker.
IIUC, we will now allow a program like:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {
    return dll_import_constexpr_ref;
}

Here, get will load dll_import_constexpr_ref. However, what will dll_import_constexpr_ref hold? It ought to hold the contents of __imp_?dll_import_int@@3HA. However, we can't dereference __imp_?dll_import_int@@3HA to get to its contents.

@majnemer Thanks for the review.

This test case doesn't link with MSVC. It will generate this error:
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test1.exe
test1.obj
test1.obj : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
test1.exe : fatal error LNK1120: 1 unresolved externals

The symbols generated with MSVC are:
07 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)
015 00000000 SECT6 notype Static | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)

Without this patch this test case errors. With this patch clang will generate these symbols:

010 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
012 00000000 SECT5 notype External | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)

and will error at link time with this error:
test1-f1f63b.o : error LNK2019: unresolved external symbol "declspec(dllimport) int dll_import_int" (imp_?dll_import_int@@3HA) referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
test1-f1f63b.o : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
a.exe : fatal error LNK1120: 2 unresolved externals

I think that's the behavior expected, right?

[majnemer]

In D117569#3258307, @zahiraam wrote:

In D117569#3257121, @majnemer wrote:

I have a question regarding how this work with respect to the dllimport semantics known by the linker.
IIUC, we will now allow a program like:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {
    return dll_import_constexpr_ref;
}

Here, get will load dll_import_constexpr_ref. However, what will dll_import_constexpr_ref hold? It ought to hold the contents of __imp_?dll_import_int@@3HA. However, we can't dereference __imp_?dll_import_int@@3HA to get to its contents.

@majnemer Thanks for the review.

This test case doesn't link with MSVC. It will generate this error:
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test1.exe
test1.obj
test1.obj : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
test1.exe : fatal error LNK1120: 1 unresolved externals

The symbols generated with MSVC are:
07 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)
015 00000000 SECT6 notype Static | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)

Without this patch this test case errors. With this patch clang will generate these symbols:

010 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
012 00000000 SECT5 notype External | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)

and will error at link time with this error:
test1-f1f63b.o : error LNK2019: unresolved external symbol "declspec(dllimport) int dll_import_int" (imp_?dll_import_int@@3HA) referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
test1-f1f63b.o : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
a.exe : fatal error LNK1120: 2 unresolved externals

I think that's the behavior expected, right?

My interpretation is that MSVC has a bug: it is forming a reference to ?dll_import_int@@3HA and not __imp_?dll_import_int@@3HA. Could you run a more complete experiment where you have a dll which exports the symbol and you try to import it?

[zahiraam]

In D117569#3259255, @majnemer wrote:

In D117569#3258307, @zahiraam wrote:

In D117569#3257121, @majnemer wrote:

I have a question regarding how this work with respect to the dllimport semantics known by the linker.
IIUC, we will now allow a program like:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {
    return dll_import_constexpr_ref;
}

Here, get will load dll_import_constexpr_ref. However, what will dll_import_constexpr_ref hold? It ought to hold the contents of __imp_?dll_import_int@@3HA. However, we can't dereference __imp_?dll_import_int@@3HA to get to its contents.

@majnemer Thanks for the review.

This test case doesn't link with MSVC. It will generate this error:
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test1.exe
test1.obj
test1.obj : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
test1.exe : fatal error LNK1120: 1 unresolved externals

The symbols generated with MSVC are:
07 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)
015 00000000 SECT6 notype Static | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)

Without this patch this test case errors. With this patch clang will generate these symbols:

010 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
012 00000000 SECT5 notype External | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)

and will error at link time with this error:
test1-f1f63b.o : error LNK2019: unresolved external symbol "declspec(dllimport) int dll_import_int" (imp_?dll_import_int@@3HA) referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
test1-f1f63b.o : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
a.exe : fatal error LNK1120: 2 unresolved externals

I think that's the behavior expected, right?

My interpretation is that MSVC has a bug: it is forming a reference to ?dll_import_int@@3HA and not __imp_?dll_import_int@@3HA. Could you run a more complete experiment where you have a dll which exports the symbol and you try to import it?

This is what I did (before the complete experiment).
For this test case:

int& get() {

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;

return dll_import_constexpr_ref;

}

int main() {

get();

return 0;

}
This is generating this symbol (with imp):
ksh-3.2$ dumpbin /symbols test2.obj | grep dll
015 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
ksh-3.2$

With clang (with this patch) it is generating the same symbol:
ksh-3.2$ dumpbin /symbols test2.o | grep dll
00E 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
ksh-3.2$

For this test case:
extern int __declspec(dllexport) dll_export_int;
constexpr int& dll_export_constexpr_ref = dll_export_int;

int& get() {

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
return dll_export_constexpr_ref;

}

int main() {

get();

return 0;

}

MSVC is generating these symbols:
ksh-3.2$ dumpbin /symbols test3.obj | grep dll
007 00000000 UNDEF notype External | ?dll_export_int@@3HA (int dll_export_int)
018 00000000 SECT6 notype Static | ?dll_export_constexpr_ref@@3AEAHEA (int & dll_export_constexpr_ref)
019 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
ksh-3.2$

clang (with this patch) is generating an error:
test3.cpp:2:16: error: constexpr variable 'dll_export_constexpr_ref' must be

initialized by a constant expression

constexpr int& dll_export_constexpr_ref = dll_export_int;

^                          ~~~~~~~~~~~~~~

1 error generated.

Your thoughts?

[majnemer]

Your example is different from mine as it nests the constexpr variable inside the function rather than having it at translation-unit scope.

[zahiraam]

In D117569#3259928, @majnemer wrote:

Your example is different from mine as it nests the constexpr variable inside the function rather than having it at translation-unit scope.

And I suppose we are interested in the latter?

In D117569#3259928, @majnemer wrote:

Your example is different from mine as it nests the constexpr variable inside the function rather than having it at translation-unit scope.

Aargh! Getting lots of link errors with various tests I tried.
Tried this:
dll.cpp:
__declspec(dllexport) int& get() {

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;

return dll_import_constexpr_ref;

}

testapp.cpp:
extern int& __declspec(dllimport) get();

int main() {

get();

return 0;

}

$ cl dll.cpp /LD /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30133 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

dll.cpp
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:dll.dll
/dll
/implib:dll.lib
dll.obj

Creating library dll.lib and object dll.exp

dll.obj : error LNK2019: unresolved external symbol "declspec(dllimport) int dll_import_int" (imp_?dll_import_int@@3HA) referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
dll.dll : fatal error LNK1120: 1 unresolved externals
$
Can't seem to find the right combination to find the potential bug!

Would that be enough to show that there is a MS bug?

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;

int f() { return dll_import_constexpr_ref; }
int main() { return f(); }

Compiled with clang:
$ dumpbin /symbols a.o | grep dll
010 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
012 00000000 SECT5 notype External | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)

Compiled with MSVC:
$ dumpbin /symbols a.obj | grep dll
007 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)
015 00000000 SECT6 notype Static | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
$

[zahiraam]

@majnemer

I did take an example completely different with no use of the constexpr in order to understand (at least for me) when the _imp prefix is generated with CL.
This is sample.cpp:
#include<iostream>

__declspec(dllexport) void PrintHello()
{

std::cout << "hello" << std::endl;

}

$ cl sample.cpp /LD /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

sample.cpp
Microsoft (R) Incremental Linker Version 14.16.27045.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:sample.dll
/dll
/implib:sample.lib
sample.obj

Creating library sample.lib and object sample.exp

$
This is testapp.cpp:
extern void __declspec(dllimport)PrintHello();

void main()
{

PrintHello();

}

$ cl testapp.cpp /EHsc /link sample.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

testapp.cpp
Microsoft (R) Incremental Linker Version 14.16.27045.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:testapp.exe
sample.lib
testapp.obj
$
$ dumpbin /symbols testapp.obj | grep imp
008 00000000 UNDEF notype External | imp_?PrintHello@@YAXXZ (declspec(dllimport) void __cdecl PrintHello(void))
$

My understanding that the _imp prefix is generated because of the dllimport in testapp.cpp.
So if we go back to the test case above:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {

return dll_import_constexpr_ref;

}
int main () {

get();
return 0;

}

CLANG (with this patch and ICL for that matter) generates the symbol:

011 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)

but not MSVC. This seems incorrect to me since the _imp prefix is always generated for dllimport symbols?

[zahiraam]

In D117569#3262595, @zahiraam wrote:

@majnemer

I did take an example completely different with no use of the constexpr in order to understand (at least for me) when the _imp prefix is generated with CL.
This is sample.cpp:
#include<iostream>

__declspec(dllexport) void PrintHello()
{

std::cout << "hello" << std::endl;

}

$ cl sample.cpp /LD /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

sample.cpp
Microsoft (R) Incremental Linker Version 14.16.27045.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:sample.dll
/dll
/implib:sample.lib
sample.obj

Creating library sample.lib and object sample.exp

$
This is testapp.cpp:
extern void __declspec(dllimport)PrintHello();

void main()
{

PrintHello();

}

$ cl testapp.cpp /EHsc /link sample.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

testapp.cpp
Microsoft (R) Incremental Linker Version 14.16.27045.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:testapp.exe
sample.lib
testapp.obj
$
$ dumpbin /symbols testapp.obj | grep imp
008 00000000 UNDEF notype External | imp_?PrintHello@@YAXXZ (declspec(dllimport) void __cdecl PrintHello(void))
$

My understanding that the _imp prefix is generated because of the dllimport in testapp.cpp.
So if we go back to the test case above:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {

return dll_import_constexpr_ref;

}
int main () {

get();
return 0;

}

CLANG (with this patch and ICL for that matter) generates the symbol:

011 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)

but not MSVC. This seems incorrect to me since the _imp prefix is always generated for dllimport symbols?

OTOH it does seem odd that clang is generating for the test case 2 UNDEF symbols. One with the _imp mangling and one without?

[zahiraam]

@majnemer Any feedback please? thanks.

[zahiraam]

@majnemer Review please :)

clang/lib/AST/ExprConstant.cpp

static bool CheckLValueConstantExpression(EvalInfo &Info, SourceLocation Loc,
 
   if (BaseVD) {
     if (const VarDecl *Var = dyn_cast<const VarDecl>(BaseVD)) {
       // Check if this is a thread-local variable.
       if (Var->getTLSKind())
         // FIXME: Diagnostic!
         return false;
 
-      // A dllimport variable never acts like a constant, unless we're
-      // evaluating a value for use only in name mangling.
-      if (!isForManglingOnly(Kind) && Var->hasAttr<DLLImportAttr>())
+      // A dllimport variable in C99, or a dllexport variable in C++ never acts
+      // like a constant, unless we're evaluating a value for use only in name
+      // mangling.
+      if (Info.getLangOpts().C99 && !isForManglingOnly(Kind) &&
+              Var->hasAttr<DLLImportAttr>() ||
+          Info.getLangOpts().CPlusPlus && !isForManglingOnly(Kind) &&
+              Var->hasAttr<DLLExportAttr>())
         // FIXME: Diagnostic!
         return false;
 
       // In CUDA/HIP device compilation, only device side variables have
       // constant addresses.
       if (Info.getCtx().getLangOpts().CUDA &&
           Info.getCtx().getLangOpts().CUDAIsDevice &&
           Info.getCtx().CUDAConstantEvalCtx.NoWrongSidedVars) {

clang/test/CodeGenCXX/PR19955.cpp

 // RUN: %clang_cc1 -triple i686-windows-msvc -fms-extensions -fno-rtti -emit-llvm -std=c++1y -O0 -o - %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -fms-extensions -fno-rtti -emit-llvm -std=c++1y -O0 -o - %s | FileCheck %s --check-prefix X64
 
 extern int __declspec(dllimport) var;
 extern void __declspec(dllimport) fun();
 
 extern int *varp;
 int *varp = &var;
-// CHECK-DAG: @"?varp@@3PAHA" = dso_local global i32* null
-// X64-DAG: @"?varp@@3PEAHEA" = dso_local global i32* null
+// CHECK-DAG: @"?var@@3HA" = external dllimport global i32
+// CHECK-DAG: @"?varp@@3PAHA" = dso_local global i32* @"?var@@3HA"
+// X64-DAG: @"?var@@3HA" = external dllimport global i32, align 4
+// X64-DAG: @"?varp@@3PEAHEA" = dso_local global i32* @"?var@@3HA"
 
 extern void (*funp)();
 void (*funp)() = &fun;
 // CHECK-DAG: @"?funp@@3P6AXXZA" = dso_local global void ()* null
 // X64-DAG: @"?funp@@3P6AXXZEA" = dso_local global void ()* null
 
-// CHECK-LABEL: @"??__Evarp@@YAXXZ"
-// CHECK-DAG: store i32* @"?var@@3HA", i32** @"?varp@@3PAHA"
-
-// X64-LABEL: @"??__Evarp@@YAXXZ"
-// X64-DAG: store i32* @"?var@@3HA", i32** @"?varp@@3PEAHEA"
-
 // CHECK-LABEL: @"??__Efunp@@YAXXZ"()
 // CHECK-DAG: store void ()* @"?fun@@YAXXZ", void ()** @"?funp@@3P6AXXZA"
 
 // X64-LABEL: @"??__Efunp@@YAXXZ"()
 // X64-DAG: store void ()* @"?fun@@YAXXZ", void ()** @"?funp@@3P6AXXZEA"

clang/test/CodeGenCXX/dllimport.cpp

 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M32 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-msvc -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC --check-prefix=M64 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-gnu    -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s         -w | FileCheck --check-prefix=GNU --check-prefix=G32 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple x86_64-windows-gnu  -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s         -w | FileCheck --check-prefix=GNU %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=18.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M18 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=19.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M19 %s
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-gnu    -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O1 -fno-experimental-new-pass-manager -o - %s         -w | FileCheck --check-prefix=GO1 %s
 
 // CHECK-NOT doesn't play nice with CHECK-DAG, so use separate run lines.
 // RUN: %clang_cc1 -disable-noundef-analysis -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC2 %s

 // MO1-DAG: @"??_B?1??inlineStaticLocalsFunc@@YAHXZ@51" = available_externally dllimport global i32 0
 inline int __declspec(dllimport) inlineStaticLocalsFunc() {
   static int x = f();
   return x++;
 };
 USE(inlineStaticLocalsFunc);
 
 // The address of a dllimport global cannot be used in constant initialization.
-// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal global [1 x i32*] zeroinitializer
-// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal global [1 x i32*] zeroinitializer
+// M32-DAG: @"?arr@?1??initializationFunc@@YAPAHXZ@4QBQAHB" = internal constant [1 x i32*] [i32* @"?ExternGlobalDecl@@3HA"]
+// GNU-DAG: @_ZZ18initializationFuncvE3arr = internal constant [1 x i32*] [i32* @ExternGlobalDecl]
 int *initializationFunc() {
   static int *const arr[] = {&ExternGlobalDecl};
   return arr[0];
 }
 USE(initializationFunc);
 
 
 //===----------------------------------------------------------------------===//

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}}
+constexpr int *varp = &var;
 
 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;

clang/test/SemaCXX/dllimport-constexpr.cpp

 
 // Member pointer instantiation.
 template <void (Foo::*MP)()> struct TemplateMemPtr { };
 TemplateMemPtr<&Foo::imported_method> instantiate_mp;
 
 // constexpr initialization doesn't work for dllimport things.
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (*constexpr_import_func)() = &imported_func;
-// expected-error@+1{{must be initialized by a constant expression}}
 constexpr int *constexpr_import_int = &imported_int;
 // expected-error@+1{{must be initialized by a constant expression}}
 constexpr void (Foo::*constexpr_memptr)() = &Foo::imported_method;
 
 // We make dynamic initializers for 'const' globals, but not constexpr ones.
 void (*const const_import_func)() = &imported_func;
 int *const const_import_int = &imported_int;
 void (Foo::*const const_memptr)() = &Foo::imported_method;
 
 // Check that using a non-type template parameter for constexpr global
 // initialization is correctly diagnosed during template instantiation.
 template <void (*FP)()> struct StaticConstexpr {
   // expected-error@+1{{must be initialized by a constant expression}}
   static constexpr void (*g_fp)() = FP;
 };
 void instantiate3() {
   // expected-note@+1 {{requested here}}
   StaticConstexpr<imported_func>::g_fp();
 }
+
+void foo() {
+  extern int __declspec(dllimport) dll_import_int;
+  constexpr int &dll_import_constexpr_ref = dll_import_int;
+}
+
+extern int __declspec(dllimport) dll_import_int;
+constexpr int &dll_import_constexpr_ref = dll_import_int;
+int goo() {
+  return dll_import_constexpr_ref;
+}