Commit Graph

7 Commits

Author SHA1 Message Date
John McCall
1950a11939 Don't emit derived-to-base destructor aliases if we don't have a definition
for the base destructor, because aliases to declarations aren't legal.

Fixes PR 6471.

llvm-svn: 97637
2010-03-03 03:40:11 +00:00
John McCall
f8ff7b9fd1 Perform two more constructor/destructor code-size optimizations:
1) emit base destructors as aliases to their unique base class destructors
under some careful conditions.  This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.

2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor.  This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).

These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.

llvm-svn: 96842
2010-02-23 00:48:20 +00:00
John McCall
b81884d347 More refactoring around constructor/destructor code generation.
Fix some bugs with function-try-blocks and simplify normal try-block
code generation.

This implementation excludes a deleting destructor's call to
operator delete() from the function-try-block, which I believe
is correct but which I can't find straightforward support for at
a moment's glance.

llvm-svn: 96670
2010-02-19 09:25:03 +00:00
Daniel Dunbar
8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Anders Carlsson
dee9a30204 Unify the way destructor epilogues are generated for synthesized and regular destructors. Also fix PR5529.
llvm-svn: 89034
2009-11-17 04:44:12 +00:00
Douglas Gregor
369acf9304 CodeGen may see out-of-line declarations of the various special member
functions when they are explicitly declared, e.g., via a function
template specialization or explicit template instantiation
declaration. Don't try to synthesize bodies for the special member
functions in this case; rather, check whether we have an implicit
declaration and, if so, synthesize the appropriate function
body. Fixes PR5084.

llvm-svn: 83212
2009-10-01 20:44:19 +00:00
Anders Carlsson
6b8b4b459d We can generate constructors/destructors with base classes and non-trivial fields just fine now.
llvm-svn: 80701
2009-09-01 18:33:46 +00:00