| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operator overloads out of line.
This seems to negatively affect compile time onsome ObjC tests
(which use a lot of partial diagnostics I assume). I have to come
up with a way to keep them inline without including Diagnostic.h
everywhere. Now adding a new diagnostic requires a full rebuild
of e.g. the static analyzer which doesn't even use those diagnostics.
This reverts commit 6496bd10dc3a6d5e3266348f08b6e35f8184bc99.
This reverts commit 7af19b817ba964ac560b50c1ed6183235f699789.
This reverts commit fdd15602a42bbe26185978ef1e17019f6d969aa7.
This reverts commit 00bd44d5677783527d7517c1ffe45e4d75a0f56f.
This reverts commit ef9b60ffed980864a8db26ad30344be429e58ff5.
llvm-svn: 150006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Capturing variables by-reference and by-copy within a lambda
- The representation of lambda captures
- The creation of the non-static data members in the lambda class
that store the captured variables
- The initialization of the non-static data members from the
captured variables
- Pretty-printing lambda expressions
There are a number of FIXMEs, both explicit and implied, including:
- Creating a field for a capture of 'this'
- Improved diagnostics for initialization failures when capturing
variables by copy
- Dealing with temporaries created during said initialization
- Template instantiation
- AST (de-)serialization
- Binding and returning the lambda expression; turning it into a
proper temporary
- Lots and lots of semantic constraints
- Parameter pack captures
llvm-svn: 149977
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
llvm-svn: 149781
|
|
|
|
|
|
|
|
|
|
| |
The recent support for potential constant expressions exposed a bug in the
implementation of libstdc++4.6, where numeric_limits<int>::min() is defined
as (int)1 << 31, which isn't a constant expression. Disable the 'constexpr
function never produces a constant expression' error inside system headers
to compensate.
llvm-svn: 149729
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
| |
llvm-svn: 149463
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.
llvm-svn: 149108
|
|
|
|
|
|
| |
to be compared to integer.
llvm-svn: 149059
|
|
|
|
| |
llvm-svn: 149045
|
|
|
|
| |
llvm-svn: 148987
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for it to be used in converted constant expression checking, and fix a couple
of issues:
- Conversion operators implicitly invoked prior to the narrowing conversion
were not being correctly handled when determining whether a constant value
was narrowed.
- For conversions from floating-point to integral types, the diagnostic text
incorrectly always claimed that the source expression was not a constant
expression.
llvm-svn: 148381
|
|
|
|
|
|
| |
builtin.
llvm-svn: 148374
|
|
|
|
| |
llvm-svn: 148333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
|
|
|
|
|
|
|
| |
designator invalid. (Since we can't read the value of such a pointer, this only
affects the quality of diagnostics.)
llvm-svn: 148208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APValue::Array and APValue::MemberPointer. All APValue values can now be emitted
as constants.
Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other
entrypoints dealing with constant member pointers are no longer necessary and
will be removed in a later change.
Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to
VarDecl::evaluateValue. This performs caching and deals with the nasty cases in
C++11 where a non-const object's initializer can refer indirectly to
previously-initialized fields within the same object.
Building the intermediate APValue object incurs a measurable performance hit on
pathological testcases with huge initializer lists, so we continue to build IR
directly from the Expr nodes for array and record types outside of C++11.
llvm-svn: 148178
|
|
|
|
|
|
| |
<rdar://problem/10691092>.
llvm-svn: 148157
|
|
|
|
|
|
|
|
|
| |
zero-initialize the first union member. Also fix a bug where initializing an
array of types compatible with wchar_t from a wide string literal failed in C,
and fortify the C++ tests in this area. This part can't be tested without a code
change to enable array evaluation in C (where an existing test fails).
llvm-svn: 148035
|
|
|
|
|
|
| |
in a constant expression, for compatibility with g++.
llvm-svn: 148020
|
|
|
|
|
|
| |
complete, remove some code from CGExprConstant which is no longer necessary. While I'm here, a couple minor tweaks to _Complex-in-C++. (Specifically, make _Complex types literal types, and don't warn for _Complex int.)
llvm-svn: 147840
|
|
|
|
|
|
|
| |
constructors. These are a special case whose behavior cannot be modeled as a
user-written constructor.
llvm-svn: 147839
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|