| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
uncommon cases. <rdar://problem/10962435>.
llvm-svn: 154794
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lvalue during constant expression evaluation.
Otherwise we would get this error in C++11 mode (because of a recent change):
error: non-type template argument of type 'const _GUID *' is not a constant expression
For code like:
template <const GUID* g = &__uuidof(struct_with_uuid)>
class COM_CLASS { };
llvm-svn: 154790
|
|
|
|
|
|
|
|
|
| |
initialize an array of unsigned char. Outside C++11 mode, this bug was benign,
and just resulted in us emitting a constant which was double the required
length, padded with 0s. In C++11, it resulted in us generating an array whose
first element was something like i8 ptrtoint ([n x i8]* @str to i8).
llvm-svn: 154756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.
Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.
With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.
llvm-svn: 154640
|
|
|
|
|
|
|
|
|
| |
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
|
|
|
|
|
|
| |
converting from std::nullptr_t, the subexpression might have side-effects.
llvm-svn: 154278
|
|
|
|
|
|
|
| |
template parameters of pointer, pointer-to-member, or nullptr_t
type in C++11. Fixes PR9700 / <rdar://problem/11193097>.
llvm-svn: 154219
|
|
|
|
|
|
|
|
| |
don't
evaluate RHS if LHS could not be evaluated and keepEvaluatingAfterFailure() is false.
llvm-svn: 153235
|
|
|
|
|
|
|
|
|
|
|
| |
non-constant value encountered. This allows the evaluator to deduce that
expressions like (x < 5 || true) is equal to true. Previously, it would visit
x and determined that the entire expression is could not evaluated to a
constant.
This fixes PR12318.
llvm-svn: 153226
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to handle extreme cases of chained binary operators without causing stack
overflow.
The binary operators that are handled with the data recursive evaluator are
comma, logical, or operators that have operands with integral or enumeration type.
Part of rdar://10941790.
llvm-svn: 152819
|
|
|
|
| |
llvm-svn: 152818
|
|
|
|
|
|
|
|
| |
breaking bootstrap. No test yet: it's quite hard to tickle the failure case.
The specific testcase for this wouldn't be useful for testing anything more
general than a reintroduction of this precise bug in any case.
llvm-svn: 152775
|
|
|
|
|
|
| |
computing expr source...", it breaks bootstrap.
llvm-svn: 152772
|
|
|
|
|
|
|
|
|
|
| |
locations for diagnostics we're not going to emit, and don't track the subobject
designator outside C++11 (since we're not going to use it anyway).
This seems to give about a 0.5% speedup on 403.gcc/combine.c, but the results
were sufficiently noisy that I can't reject the null hypothesis.
llvm-svn: 152761
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 152665
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
| |
llvm-svn: 152526
|
|
|
|
|
|
|
|
| |
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
|
|
|
|
|
|
|
|
| |
copy-construction, which Daniel Dunbar reports as giving a 0.75% speedup on
403.gcc/combine.c. The performance differences on my constexpr torture tests
are below the noise floor.
llvm-svn: 152455
|
|
|
|
|
|
|
| |
- This function is not at all free; pass it around along some hot paths instead
of recomputing it deep inside various VarDecl methods.
llvm-svn: 152363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.
UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).
User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.
This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.
llvm-svn: 152211
|
|
|
|
|
|
| |
producing a C-only diagnostic.
llvm-svn: 152181
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
|
|
|
|
|
|
| |
resolution of core issue 1454.
llvm-svn: 151991
|
|
|
|
|
|
| |
Needs llvm update.
llvm-svn: 151829
|
|
|
|
|
|
|
|
| |
depth and error if we exceed a max value, to make sure we avoid a stack overflow.
This is a hacky temporary fix. rdar://10913206.
llvm-svn: 151585
|
|
|
|
| |
llvm-svn: 151548
|
|
|
|
|
|
|
|
|
|
|
| |
Original log:
When evaluating integer expressions handle logical operators outside
VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.
Fixes rdar://10913206.
llvm-svn: 151464
|
|
|
|
|
|
|
|
|
| |
VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.
Fixes rdar://10913206.
llvm-svn: 151460
|
|
|
|
|
|
|
| |
the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the declaration is.
llvm-svn: 151399
|
|
|
|
|
|
| |
hasTrivialMoveConstructor().
llvm-svn: 151354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block pointer that returns a block literal which captures (by copy)
the lambda closure itself. Some aspects of the block literal are left
unspecified, namely the capture variable (which doesn't actually
exist) and the body (which will be filled in by IRgen because it can't
be written as an AST).
Because we're switching to this model, this patch also eliminates
tracking the copy-initialization expression for the block capture of
the conversion function, since that information is now embedded in the
synthesized block literal. -1 side tables FTW.
llvm-svn: 151131
|
|
|
|
| |
llvm-svn: 151100
|
|
|
|
|
|
| |
the wrong thing.
llvm-svn: 150928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
complex numbers. Treat complex numbers as arrays of the corresponding component
type, in order to make std::complex behave properly if implemented in terms of
_Complex T.
Apparently libstdc++'s std::complex is implemented this way, and we were
rejecting a member like this:
constexpr double real() { return __real__ val; }
because it was marked constexpr but unable to produce a constant expression.
llvm-svn: 150895
|
|
|
|
|
|
|
| |
are represented as prvalues in C++; don't be fooled into thinking they're
global lvalues.
llvm-svn: 150870
|
|
|
|
|
|
| |
can be represented by an LValue, and use that to simplify the code a little.
llvm-svn: 150789
|
|
|
|
|
|
|
| |
zero-initialize class types with virtual bases when constant-evaluating an
initializer.
llvm-svn: 150770
|
|
|
|
|
|
|
|
| |
* Fix bug when determining whether && / || are potential constant expressions
* Try harder when determining whether ?: is a potential constant expression
* Produce a diagnostic on sizeof(VLA) to provide a better source location
llvm-svn: 150657
|
|
|
|
|
|
|
|
|
|
|
|
| |
to be core constant expressions (including pointers and references to
temporaries), and makes constexpr calculations Turing-complete. A Turing machine
simulator is included as a testcase.
This opens up the possibilty of removing CCValue entirely, and removing some
copies from the constant evaluator in the process, but that cleanup is not part
of this change.
llvm-svn: 150557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is general goodness because representations of member pointers are
not always equivalent across member pointer types on all ABIs
(even though this isn't really standard-endorsed).
Take advantage of the new information to teach IR-generation how
to do these reinterprets in constant initializers. Make sure this
works when intermingled with hierarchy conversions (although
this is not part of our motivating use case). Doing this in the
constant-evaluator would probably have been better, but that would
require a *lot* of extra structure in the representation of
constant member pointers: you'd really have to track an arbitrary
chain of hierarchy conversions and reinterpretations in order to
get this right. Ultimately, this seems less complex. I also
wasn't quite sure how to extend the constant evaluator to handle
foldings that we don't actually want to treat as extended
constant expressions.
llvm-svn: 150551
|
|
|
|
| |
llvm-svn: 150521
|
|
|
|
|
|
|
| |
C++11 or just C++17, restrict the set of null pointer constants in C++11 mode
back to those which were considered null in C++98.
llvm-svn: 150510
|
|
|
|
|
|
|
|
|
|
|
| |
constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.
llvm-svn: 150419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
incomplete class type which has an overloaded operator&, it's now just
unspecified whether the overloaded operator or the builtin is used.
llvm-svn: 150234
|
|
|
|
|
|
| |
lvalue-to-rvalue conversions in constant expressions.
llvm-svn: 150145
|
|
|
|
|
|
|
| |
not a constant expression, because we can't tell whether the complete class type
will have an overloaded operator&.
llvm-svn: 150066
|
|
|
|
|
|
|
|
|
|
| |
the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit
out of the sign bit still does. As promised to Howard :)
The suppression of the potential constant expression checking in system headers
is also removed, since the problem it was working around is gone.
llvm-svn: 150059
|