| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
|
|
|
|
|
|
|
| |
* support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11
* check for unspecified values in pointer comparisons and pointer subtractions
llvm-svn: 149578
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mess. According to the C++11 standard, pointer subtraction only has
undefined behavior if the difference of the array indices does not fit into a
ptrdiff_t.
However, common implementations effectively perform a char* subtraction first,
and then divide the result by the element size, which can cause overflows in
some cases. Those cases are not considered to be undefined behavior by this
change; perhaps they should be.
llvm-svn: 149490
|
|
|
|
| |
llvm-svn: 149473
|
|
|
|
| |
llvm-svn: 149467
|
|
|
|
|
|
| |
isn't, but this is just a (reported) defect in the wording.
llvm-svn: 149448
|
|
|
|
|
|
|
| |
unspecified unless the pointers are equal; therefore, such a comparison is not
a constant expression unless the pointers are equal.
llvm-svn: 149366
|
|
|
|
|
|
|
|
|
| |
-INT_MIN and INT_MIN / -1
Shift by a negative or too large quantity
Left shift of negative value
Overflow in left shift
llvm-svn: 149344
|
|
|
|
|
|
|
| |
As Eli points out, this is implementation-defined, and the way we define it
makes this fine.
llvm-svn: 149327
|
|
|
|
|
|
| |
expressions in C++11.
llvm-svn: 149286
|
|
|
|
|
|
|
|
|
|
| |
values and non-type template arguments of integral and enumeration types.
This change causes some legal C++98 code to no longer compile in C++11 mode, by
enforcing the C++11 rule that narrowing integral conversions are not permitted
in the final implicit conversion sequence for the above cases.
llvm-svn: 148439
|
|
|
|
|
|
|
|
| |
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.
llvm-svn: 148209
|
|
|
|
|
|
| |
in a constant expression, for compatibility with g++.
llvm-svn: 148020
|
|
|
|
|
|
|
| |
pointer-arithmetic-related undefined behavior and unspecified results. We
continue to fold such values, but now notice they aren't constant expressions.
llvm-svn: 147659
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 147362
|
|
|
|
| |
llvm-svn: 147290
|
|
|
|
|
|
| |
constructor call when appropriate. Thanks to Eli for spotting this.
llvm-svn: 147271
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 147035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
llvm-svn: 146856
|
|
|
|
| |
llvm-svn: 146759
|
|
|
|
|
|
|
|
|
|
| |
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
llvm-svn: 146749
|
|
|
|
|
|
|
|
| |
freebsd bots happy. In the longer term, we should have a mechanism for moving
constexpr recursion off the call stack, to support the default limit of 512
suggested by the standard.
llvm-svn: 146596
|
|
|
|
|
|
| |
be constant expressions.
llvm-svn: 146479
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
that the unevaluated subexpressions of &&, ||, and ? : are not
considered when determining whether the expression is a constant
expression. Also, turn the "used in its own initializer" warning into
a runtime-behavior warning, so that it doesn't fire when a variable is
used as part of an unevaluated subexpression of its own initializer.
Fixes PR9999.
llvm-svn: 131968
|