[PATCH] Fix for bug 17427 - Assertion failed: "Computed __func__ length differs from type!"
Reid Kleckner
rnk at google.com
Tue Oct 7 16:57:53 PDT 2014
Thanks for the cleanup! Looks good with a fix for the func-inside-block-inside-ctor test case.
================
Comment at: lib/AST/Expr.cpp:521
@@ +520,3 @@
+ else
+ MC->mangleBlock(DC, BD, Out);
+ return Out.str();
----------------
I believe this will assert in this code:
struct A {
const char *s;
A() {
const char *(^b)() = ^() {
return __func__;
};
s = b();
};
A a;
You probably need to handle the ctor / dtor cases separately, as is done in CodeGenModule::getBlockMangledName. Using Ctor_Base and Dtor_Base should be correct. I don't think we should ever emit two different block implementations for the base ctor and complete ctor. =/
================
Comment at: lib/CodeGen/CGExpr.cpp:2061
@@ +2060,3 @@
+ FnName = FnName.substr(1);
+ std::string NameItems[] = {
+ PredefinedExpr::getIdentTypeName(E->getIdentType()), FnName};
----------------
I think this can be an array of StringRefs to avoid building two tmp strings.
================
Comment at: lib/CodeGen/CodeGenModule.cpp:2751-2752
@@ -2749,3 +2750,4 @@
if (!LangOpts.WritableStrings && !LangOpts.Sanitize.Address &&
- getCXXABI().getMangleContext().shouldMangleStringLiteral(S)) {
+ getCXXABI().getMangleContext().shouldMangleStringLiteral(S) &&
+ Name == ".str") {
llvm::raw_svector_ostream Out(MangledNameBuffer);
----------------
This change will cause duplicate string literals to not be merged across TUs on Windows. Just mangle the string literal if the ABI says we should.
================
Comment at: test/CodeGenCXX/ms_wide_predefined_expr.cpp:3
@@ -2,3 +2,3 @@
-// CHECK: @"\01??_C at _19DPFBEKIN@?$AAf?$AAu?$AAn?$AAc?$AA?$AA@" = linkonce_odr unnamed_addr constant [5 x i16] [i16 102, i16 117, i16 110, i16 99, i16 0], align 2
+// CHECK: @"L__FUNCTION__.?func@@YAXXZ" = private unnamed_addr constant [5 x i16] [i16 102, i16 117, i16 110, i16 99, i16 0], align 2
----------------
This test in particular should not change.
http://reviews.llvm.org/D5365
More information about the cfe-commits
mailing list