rjmccall added inline comments.
================
Comment at: test/CodeGenCXX/static-init.cpp:14
+// CHECK98: @_ZZN5test414useStaticLocalEvE3obj = linkonce_odr global
%"struct.test4::HasVTable" zeroinitializer, comdat, align 8
+// CHECK11: @_ZZN5test414useStaticLocalEvE3obj = linkonce_odr global { i8** }
{ i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }*
@_ZTVN5test49HasVTableE, i32 0, inrange i32 0, i32 2) }, comdat, align 8
----------------
rnk wrote:
> rjmccall wrote:
> > Interesting. It looks to me like the C++11 IR pattern is actually the only
> > one that would've exposed the bug that Reid was fixing in r242704. Reid,
> > do you agree?
> I'm not sure I follow exactly, but I think what's going on here is that, in
> C++11, the implicit default constructor is constexpr. I'm not sure how that
> feeds into what type we choose to use for the global.
The global gets created using its formal type, and then we need to give it an
initializer, which in some cases will have a different type, and so we need to
replace the global with something with the right type. Maybe that's not the
type mismatch you were fixing in that revision?
Really I'm telling you to please go ahead and finish your
eliminating-types-from-pointer work. :)
https://reviews.llvm.org/D24812
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
