| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
know are going to be constant-evaluated.
Any relevant diagnostics should be produced by constant expression evaluation.
llvm-svn: 314067
|
|
|
|
|
|
|
| |
temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member access.
llvm-svn: 288563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
This is a re-commit of r284800.
llvm-svn: 284890
|
|
|
|
|
|
|
|
| |
rules."
This reverts commit r284800, as it failed all ARM/AArch64 bots.
llvm-svn: 284811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
llvm-svn: 284800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switch the evaluation from isIntegerConstantExpr to EvaluateAsInt.
EvaluateAsInt will evaluate more types of expressions than
isIntegerConstantExpr.
Move one case from -Wsign-conversion to -Wconstant-conversion. The case is:
1) Source and target types are signed
2) Source type is wider than the target type
3) The source constant value is positive
4) The conversion will store the value as negative in the target.
llvm-svn: 259271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
% ./clang -Wshift-negative-value emit.c
emit.c:3:14: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
int a = -1 << 3;
~~ ^
1 warning generated.
PR: 24026
Differential Revision: http://reviews.llvm.org/D10938
Reviewed by: rsmith
llvm-svn: 241478
|
|
|
|
|
|
|
|
|
| |
arguments).
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
|
|
|
|
| |
llvm-svn: 219222
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 205757
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
llvm-svn: 204164
|
|
|
|
|
|
|
|
|
| |
We would previously not diagnose this which would lead to crashes (on
very strange code).
This fixes PR17675.
llvm-svn: 193397
|
|
|
|
|
|
|
| |
only permitted if the source object is of class type, and should materialize a
temporary for the reference to bind to.
llvm-svn: 184017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
materialized temporary with the corresponding MaterializeTemporaryExpr. This is
groundwork for providing C++11's guaranteed static initialization for global
references bound to lifetime-extended temporaries (if the initialization is a
constant expression).
In passing, fix a couple of bugs where some evaluation failures didn't trigger
diagnostics, and a rejects-valid where potential constant expression testing
would assume that it knew the dynamic type of *this and would reject programs
which relied on it being some derived type.
llvm-svn: 183093
|
|
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
|
|
|
|
|
| |
decidedly non-reference, non-pointer type. Fixes <rdar://problem/13090123>.
llvm-svn: 173747
|
|
|
|
|
|
| |
constant evaluation. <rdar://problem/11874571>.
llvm-svn: 160394
|
|
|
|
|
|
|
|
|
| |
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.
llvm-svn: 151881
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
lvalue-to-rvalue conversions on the source type of the conversion, not the
target type (which has them removed for non-class types).
llvm-svn: 149796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|