| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
address-of-label differences).
llvm-svn: 147631
|
| |
|
|
|
|
|
|
|
|
| |
address-of-label expressions. Add support to Evaluate and CGExprConstant for generating/handling them. Remove the special-case for such differences in Expr::isConstantInitializer.
With that done, remove a bunch of buggy code from CGExprConstant for handling scalar expressions which is no longer necessary.
Fixes PR11705.
llvm-svn: 147561
|
| |
|
|
|
|
| |
independent of whether we're in C++11 mode.
llvm-svn: 147503
|
| |
|
|
|
|
| |
Anton Lokhmotov.
llvm-svn: 147496
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
clients. No functionality change.
llvm-svn: 147318
|
| |
|
|
| |
llvm-svn: 147290
|
| |
|
|
|
|
| |
constructor call when appropriate. Thanks to Eli for spotting this.
llvm-svn: 147271
|
| |
|
|
| |
llvm-svn: 147137
|
| |
|
|
|
|
| |
definition would satisfy the constexpr requirements.
llvm-svn: 147128
|
| |
|
|
|
|
| |
by string literals.
llvm-svn: 147120
|
| |
|
|
| |
llvm-svn: 147067
|
| |
|
|
|
|
| |
constant expressions.
llvm-svn: 147035
|
| |
|
|
|
|
| |
actually requires non-trivial cleanups, so no cleanups need to be performed.
llvm-svn: 146916
|
| |
|
|
| |
llvm-svn: 146915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
(truncated)
floating literal value does not fit into the destination type. Such casts have
undefined behavior at translation time; treating them as non-ICE matches the
behavior of modern gcc versions.
llvm-svn: 146842
|
| |
|
|
| |
llvm-svn: 146813
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
be constant expressions.
llvm-svn: 146479
|
| |
|
|
| |
llvm-svn: 146395
|
| |
|
|
| |
llvm-svn: 146371
|
| |
|
|
|
|
| |
did not!
llvm-svn: 146366
|
| |
|
|
|
|
| |
diagnostics. No functionality change.
llvm-svn: 146365
|
| |
|
|
|
|
|
| |
compilation of some translation units of SPEC's 445.gobmk by ~4%, and does not
seem to cause a measurable slowdown in other cases.
llvm-svn: 146306
|
| |
|
|
|
|
|
|
|
|
|
|
| |
whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.
The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.
llvm-svn: 146289
|
| |
|
|
|
|
| |
infinite recursion due to bad OpaqueValueExpr.
llvm-svn: 146237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
documentation) with one based on what GCC's __builtin_constant_p is actually
intended to do (discovered by asking a friendly GCC developer).
In particular, an expression which folds to a pointer is now only considered to
be a "constant" by this builtin if it refers to the first character in a string
literal.
This fixes a rather subtle wrong-code issue when building with glibc. Given:
const char cs[4] = "abcd";
int f(const char *p) { return strncmp(p, cs, 4); }
... the macro magic for strncmp produces a (potentially crashing) call to
strlen(cs), because it expands to an expression starting with:
__builtin_constant_p(cs) && strlen(cs) < 4 ? /* ... */
Under the secret true meaning of __builtin_constant_p, this is guaranteed to be
safe!
llvm-svn: 146236
|
| |
|
|
|
|
|
| |
bound to not have side effects(!). Add constant-folding support for expressions
of void type, to ensure that we can still fold ((void)0, 1) as an array bound.
llvm-svn: 146000
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
evaluator into constant initializer handling / IRGen. The practical consequence
of this is that the bitcast now lives in the constant's definition, rather than
in its uses.
The code in the constant expression evaluator was producing vectors of the wrong
type and size (and possibly of the wrong value for a big-endian int-to-vector
bitcast). We were getting away with this only because we don't yet support
constant-folding of any expressions which inspect vector values.
llvm-svn: 145981
|
| |
|
|
| |
llvm-svn: 145845
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.
Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.
The -ftemplate-depth=N part of this fixes PR9890.
llvm-svn: 145045
|
| |
|
|
|
|
| |
and base-to-derived casts, and add proper handling of temporaries.
llvm-svn: 144926
|
| |
|
|
| |
llvm-svn: 144799
|
| |
|
|
|
|
|
| |
not safely derived. Don't allow lvalue-to-rvalue conversions on the result of
dereferencing such a pointer.
llvm-svn: 144783
|
| |
|
|
|
|
|
|
| |
or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.
llvm-svn: 144468
|
| |
|
|
| |
llvm-svn: 144382
|
| |
|
|
|
|
| |
please the buildbots.
llvm-svn: 144375
|
| |
|
|
|
|
|
|
|
|
|
| |
reinstates r144273; a combination of r144333's fix for NoOp rvalue-to-lvalue
casts and some corresponding changes here resolve the regression which that
caused.
This patch also adds support for some additional forms of member function call,
along with additional testing.
llvm-svn: 144369
|
| |
|
|
| |
llvm-svn: 144296
|
| |
|
|
| |
llvm-svn: 144273
|
| |
|
|
|
|
|
| |
literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.
llvm-svn: 144265
|
| |
|
|
|
|
|
| |
is currently too inefficient to allow us to use it for array initializers, but
fortunately we usually don't yet need to evaluate such initializers.
llvm-svn: 144260
|
| |
|
|
| |
llvm-svn: 144156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
llvm-svn: 144056
|
| |
|
|
| |
llvm-svn: 143922
|
| |
|
|
| |
llvm-svn: 143910
|
| |
|
|
|
|
| |
core constant value down to an APValue.
llvm-svn: 143909
|
| |
|
|
|
|
|
|
| |
partially undoes the revert in r143491, but does not introduce any new instances
of the underlying issue (which is not yet fixed) in code which does not use
the 'constexpr' keyword.
llvm-svn: 143905
|