non-constant constructors or non-trivial destructors. Plus bugfixes for
thread_local references bound to temporaries (the temporaries themselves are
lifetime-extended to become thread_local), and the corresponding case for
std::initializer_list.
llvm-svn: 179496
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
llvm-svn: 179305
linkage specification, and is marked as __attribute__((used)), try to also give
it the unmangled name (by emitting an internal linkage alias) if nothing else
within the translation unit would use that name. This allows inline asm in that
translation unit to use the entity via its unmangled name, which people
apparently rely on.
llvm-svn: 178950
This reverts commit r178497 since the backend has been fixed.
Also add a test to ensure that we're emitting template information for unions.
llvm-svn: 178587
when we actually end a lexical block.
* Added new test for line table / block cleanup.
* Follow-up to r177819 / rdar://problem/13115369
llvm-svn: 178490
* Store the .block_descriptor (instead of self) in the alloca so we
can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564
llvm-svn: 178361
This reverts commit 5035c483b7fcbf0fa2a7afba24fa35a10995d195.
This schema change wasn't necessary after all. I'm going ith a different
solution that will hopefully use space more conservatively.
llvm-svn: 178213
Summary:
The only vector types a user can pass from MSVC code to clang code are
the ones from *mmintrin.h, so we only have to match the MSVC mangling
for these types. MSVC mangles the __m128 family of types as tag types,
which we match. For other vector types, we emit a unique tag type
mangling that won't match anything produced by MSVC.
Reviewers: rjmccall
CC: chandlerc, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D576
llvm-svn: 178036
Summary:
For non-dynamic classes (no virtual bases), member data pointers are
simple offsets from the base of the record. Dynamic classes use an
aggregate for member data pointers and are therefore currently
unsupported.
Unlike Itanium, the ms ABI uses 0 to represent null for polymorphic
classes. Non-polymorphic classes use -1 like Itanium, since 0 is a
valid field offset.
Reviewers: rjmccall
CC: timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D558
llvm-svn: 177753
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
llvm-svn: 177692
This isn't necessary & with the next change to LLVM the DW_TAG_file_type entry
won't be emitted at all - only the raw filename/directory pair, so match on
that directly instead.
llvm-svn: 177609
The #line directive is mostly for backend testing (keeping these files matching
should simplify maintenance somewhat) though the corresponding backend test
improvement/update doesn't verify the file information directly just yet.
Coming in a later iteration.
llvm-svn: 177559
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
Updated from r177211.
rdar://12818789
llvm-svn: 177541
Mostly, try to depend on the annotation comments more so these tests are more
legible, brief, and agnostic to schema changes in the future (sure, they're not
agnostic to changes to the comment annotations but since they're easier to read
they should be easier to update if that happens).
llvm-svn: 177457
Checking for the annotation comment rather than the metadata values makes these
tests resilient to a coming refactor that will pull these fields out into a
separate metadata node.
llvm-svn: 177237
For constructors/desctructors that return 'this', if there exists a callsite
that returns 'this' and is immediately before the return instruction, make
sure we are using the return value from the callsite.
We don't need to keep 'this' alive through the callsite. It also enables
optimizations in the backend, such as tail call optimization.
rdar://12818789
llvm-svn: 177211
the balance between expected behavior and compatibility with the gdb
testsuite.
(GDB gets confused if we break an expression into multiple debug
stmts so we enable this behavior only for inlined functions. For the
full experience people can still use -gcolumn-info.)
llvm-svn: 177164
This fixes a crash in
namespace {
struct X {};
}
extern "C" X test2_b;
X test2_b
before we would assign different linkages to each of the test2_b decls.
llvm-svn: 176869
field to be memcpy'd, rather instead of ASTContext::getTypeAlign(<Field Type>).
For packed structs the alignment of a field may be less than the alignment of
the field's type.
<rdar://problem/13338585>
llvm-svn: 176512
[[noreturn]] function are not required to also be [[noreturn]]. We still emit
calls to virtual __attribute__((noreturn)) functions as noreturn; unlike GCC,
we do require overriders to also be noreturn for that attribute.
llvm-svn: 176476
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
Jyotsna Verma