[PATCH] D16465: [MS ABI] Prevent some expressions from evaluating to a constant
Richard Smith via cfe-commits
cfe-commits at lists.llvm.org
Fri Feb 26 18:22:11 PST 2016
rsmith added a comment.
We stand no hope of being bug-for-bug compatible with MSVC's constant expression evaluator -- we should assume there will be expressions that we evaluate as a constant and they do not, and vice versa. For reference, we have the same problem between code built by Clang and by GCC, and in some cases for linking together multiple object files compiled by clang (an initializer for a static local in an inline function can be constant in one TU but not another). But those have never been enough of a problem for us to actually fix the root cause.
Why is this set of MSVC behavior the right set to be compatible with? Is there some important code for which this makes us ABI-compatible? I really don't believe the heuristics you've got here are an exact match for the MSVC semantics...
This feels like patching the symptoms of a bigger issue; is there something we can do to address the underlying problem? Perhaps we could always emit a mutable variable for a static local, even if we are able to constant-initialize it.
================
Comment at: lib/AST/ExprConstant.cpp:9018
@@ -8917,1 +9017,3 @@
+ if (RespectMicrosoftABIIfNeeded &&
+ Ctx.getTargetInfo().getCXXABI().isMicrosoft() &&
----------------
This also needs to apply for implicitly-instantiated static data members of class templates.
================
Comment at: test/CodeGenCXX/static-init-msvc.cpp:6
@@ +5,3 @@
+
+void fun_and() {
+// CHECK-LABEL: @"\01?fun_and@@YAXXZ"()
----------------
These should all be `inline` functions. There's no need to apply any special behavior in any of these cases, as only one object file will contain a definition of the static local.
http://reviews.llvm.org/D16465
More information about the cfe-commits
mailing list