Commit Graph

5 Commits

Author SHA1 Message Date
Richard Smith 5d108606cc PR12012: Fix a regression in r150419 where we would try (and fail) to
zero-initialize class types with virtual bases when constant-evaluating an
initializer.

llvm-svn: 150770
2012-02-17 00:44:16 +00:00
Richard Smith 3607ffee5c Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
 - Instantiations of constexpr functions are always constexpr. This removes the
   need for separate declaration/definition checking, which is now gone.
 - This makes it possible for a constexpr function to be virtual, if they are
   only dependently virtual. Virtual calls to such functions are not constant
   expressions.
 - Likewise, it's now possible for a literal type to have virtual base classes.
   A constexpr constructor for such a type cannot actually produce a constant
   expression, though, so add a special-case diagnostic for a constructor call
   to such a type rather than trying to evaluate it.
 - Classes with trivial default constructors (for which value initialization can
   produce a fully-initialized value) are considered literal types.
 - Classes with volatile members are not literal types.
 - constexpr constructors can be members of non-literal types. We do not yet use
   static initialization for global objects constructed in this way.

llvm-svn: 150359
2012-02-13 03:54:03 +00:00
Richard Smith fddd384b73 Unrevert r147271, reverted in r147361.
Also temporarily remove the assumption from IR gen that we can emit IR for every
constant we can fold, since it isn't currently true in C++11, to fix PR11676.

Original comment from r147271:

constexpr: perform zero-initialization prior to / instead of performing a
constructor call when appropriate. Thanks to Eli for spotting this.

llvm-svn: 147384
2011-12-30 21:15:51 +00:00
Rafael Espindola fafe4b7572 Revert r147271. This fixes PR11676.
llvm-svn: 147362
2011-12-30 03:11:50 +00:00
Richard Smith 771c4a1775 constexpr: perform zero-initialization prior to / instead of performing a
constructor call when appropriate. Thanks to Eli for spotting this.

llvm-svn: 147271
2011-12-25 20:00:17 +00:00