| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
something. :)
llvm-svn: 249223
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the vptr store in the most-derived constructor is not behind
an invariant group barrier. Previously, the base-most vptr store would
be the one behind no barrier, and that could result in the creator of
the object thinking it had the base-most vtable.
This bug caused clang call pure virtual functions when called from
constructor body.
http://reviews.llvm.org/D13373
llvm-svn: 249197
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is dangerous to do LTO on code with strict-vtable-pointers, because
one module has invariant.group.barriers, and the other one not.
In the future I want to just strip all invariant.group metadata from
vptrs loads/stores and get rid of invariant.group.barrier calls.
http://reviews.llvm.org/D12580
llvm-svn: 247724
|
|
For more goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
http://reviews.llvm.org/D12312
llvm-svn: 247723
|