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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
