| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
No functionality change intended.
llvm-svn: 298443
|
|
This patch honors the unaligned type qualifier (currently available through he
keyword __unaligned and -fms-extensions) in CodeGen. In the current form the
patch affects declarations and expressions. It does not affect fields of
classes.
Differential Revision: https://reviews.llvm.org/D30166
llvm-svn: 297276
|
|
Summary:
The changes contained in this patch are:
1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent.
2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible.
3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results.
4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends.
@rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches.
Reviewers: rsmith, GorNishanov
Reviewed By: rsmith
Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D26057
llvm-svn: 297093
|
|
This is necessary in order for the evaluation of an _Atomic initializer for
those types to have an associated object, which an initializer for class or
array type needs.
llvm-svn: 295886
|
|
ExprConstant.cpp:6344:20: warning: comparison of integers of different
signs: 'const size_t' (aka 'const unsigned long') and 'typename
iterator_traits<Expr *const *>::difference_type' (aka 'long')
[-Wsign-compare]
llvm-svn: 295320
|
|
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
llvm-svn: 295311
|
|
of constexpr lambdas.
Enable evaluation of captures within constexpr lambdas by using a strategy similar to that used in CodeGen:
- when starting evaluation of a lambda's call operator, create a map from VarDecl's to a closure's FieldDecls
- every time a VarDecl (or '*this) that represents a capture is encountered while evaluating the expression via the expression evaluator (specifically the LValueEvaluator) in ExprConstant.cpp - it is replaced by the corresponding FieldDecl LValue (an Lvalue-to-Rvalue conversion on this LValue representation then determines the right rvalue when needed).
Thanks to Richard Smith and Hubert Tong for their review and feedback!
https://reviews.llvm.org/D29748
llvm-svn: 295279
|
|
What we want to actually control this behavior is something more local
than an EvalutationMode. Please see the linked revision for more
discussion on why/etc.
This fixes PR31843.
Differential Revision: https://reviews.llvm.org/D29469
llvm-svn: 294800
|
|
llvm-svn: 293871
|
|
This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.
rdar://problem/30111207
llvm-svn: 293596
|
|
Don't try to map an APSInt addend to an int64_t in pointer arithmetic before
bounds-checking it. This gives more consistent behavior (outside C++11, we
consistently use 2s complement semantics for both pointer and integer overflow
in constant expressions) and fixes some cases where in C++11 we would fail to
properly check for out-of-bounds pointer arithmetic (if the 2s complement
64-bit overflow landed us back in-bounds).
In passing, also fix some cases where we'd perform possibly-overflowing
arithmetic on CharUnits (which have a signed underlying type) during constant
expression evaluation.
llvm-svn: 293595
|
|
as 64 bit values for pointer arithmetic.
This fixes various ways to tickle an assertion in constant expression
evaluation when using __int128. Longer term, we need to figure out what should
happen here: either any kind of overflow in offset calculation should result in
a non-constant value or we should truncate to 64 bits. In C++11 onwards, we're
effectively already checking for overflow because we strictly enforce array
bounds checks, but even there some forms of overflow can slip past undetected.
llvm-svn: 293568
|
|
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
|
|
by providing a memchr builtin that returns char* instead of void*.
Also add a __has_feature flag to indicate the presence of constexpr forms of
the relevant <string> functions.
llvm-svn: 292555
|
|
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:
struct foo_t { union { int i; volatile int j; } u; };
__attribute__((__require_constant_initialization__))
static const foo_t x = {{0}};
Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:
union foo_u { int i; volatile int j; };
__attribute__((__require_constant_initialization__))
static const foo_u x = {0};
does have a constant initializer.
(This was triggered by musl's pthread_mutex_t type when building under C++11.)
Reviewers: rsmith
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D28427
llvm-svn: 291480
|
|
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
llvm-svn: 291418
|
|
lambda expressions.
Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.
This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);
Lambda captures are still not supported for constexpr lambdas.
llvm-svn: 291416
|
|
expression-evaluator to evaluate the static-invoker.
This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year. While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then.
I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization).
Thanks!
llvm-svn: 291397
|
|
I accidentally omitted these when refactoring this code. This caused
problems when building parts of the test-suite on MacOS.
llvm-svn: 290916
|
|
This addresses post-review feedback from r290577.
llvm-svn: 290584
|
|
operand."
Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171
Reviewers: djasper, Anastasia
Subscribers: yaxunl, cfe-commits, bader
Differential Revision: https://reviews.llvm.org/D27981
llvm-svn: 290431
|
|
This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.
Fingers crossed that this patch sticks this time. :)
Original commit message:
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
llvm-svn: 290297
|
|
This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.
Replied on the commit with more details.
llvm-svn: 290173
|
|
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, yaxunl, bader
Differential Revision: https://reviews.llvm.org/D27569
llvm-svn: 290171
|
|
This commit fails MSan when running test/CodeGen/object-size.c in
a confusing way. After some discussion with George, it isn't really
clear what is going on here. We can make the MSan failure go away by
testing for the invalid bit, but *why* things are invalid isn't clear.
And yet, other code in the surrounding area is doing precisely this and
testing for invalid.
George is going to take a closer look at this to better understand the
nature of the failure and recommit it, for now backing it out to clean
up MSan builds.
llvm-svn: 290169
|
|
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
Differential Revision: https://reviews.llvm.org/D14274
llvm-svn: 290149
|
|
llvm-svn: 289787
|
|
type differs from the type of the actual function due to having a different
exception specification.
llvm-svn: 289754
|
|
llvm-svn: 289713
|
|
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
|
|
32-bit MSVC doesn't provide more than 4 byte stack alignment by default.
This conflicts with PointerUnion's attempt to make assertions about
alignment. This fixes the problem by explicitly asking the compiler for
8 byte alignment.
llvm-svn: 289575
|
|
initialization of each array element:
* ArrayInitLoopExpr is a prvalue of array type with two subexpressions:
a common expression (an OpaqueValueExpr) that represents the up-front
computation of the source of the initialization, and a subexpression
representing a per-element initializer
* ArrayInitIndexExpr is a prvalue of type size_t representing the current
position in the loop
This will be used to replace the creation of explicit index variables in lambda
capture of arrays and copy/move construction of classes with array elements,
and also C++17 structured bindings of arrays by value (which inexplicably allow
copying an array by value, unlike all of C++'s other array declarations).
No uses of these nodes are introduced by this change, however.
llvm-svn: 289413
|
|
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.
Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.
Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.
Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.
This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.
This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.
Differential Revision: https://reviews.llvm.org/D26196
llvm-svn: 289252
|
|
mirror the description in the standard. Per DR1295, this means that binding a
const / rvalue reference to a bit-field no longer "binds directly", and per
P0135R1, this means that we materialize a temporary in reference binding
after adjusting cv-qualifiers and before performing a derived-to-base cast.
In C++11 onwards, this should have fixed the last case where we would
materialize a temporary of the wrong type (with a subobject adjustment inside
the MaterializeTemporaryExpr instead of outside), but we still have to deal
with that possibility in C++98, unless we want to start using xvalues to
represent materialized temporaries there too.
llvm-svn: 289250
|
|
When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
|
|
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
|
|
functions, in order to support constexpr std::char_traits<wchar_t>.
llvm-svn: 288193
|
|
common case of a call to a non-builtin, particularly for unoptimized ASan
builds (where the per-variable stack usage can be quite high).
llvm-svn: 287066
|
|
during constant expression evaluation.
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.
void f(char c) {
struct X {
static constexpr char f() {
return c; // error gracefully here as opposed to crashing.
}
};
int I = X::f();
}
llvm-svn: 286748
|
|
llvm-svn: 286699
|
|
support constexpr char_traits.
llvm-svn: 286678
|
|
llvm-svn: 284856
|
|
llvm-svn: 284366
|
|
llvm-svn: 283657
|
|
llvm-svn: 281923
|
|
The struct CallStackFrame is in lib/AST/ExprConstant.cpp
inside anonymous namespace.
This diff reorders the fields and removes excessive padding.
Test plan: make -j8 check-clang
Differential revision: https://reviews.llvm.org/D23901
llvm-svn: 281907
|
|
This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:
```
struct sockaddr {
/* snip */
char sa_data[14];
};
void foo(const char *s) {
size_t slen = strlen(s) + 1;
size_t added_len = slen <= 14 ? 0 : slen - 14;
struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
strcpy(sa->sa_data, s);
// ...
}
```
`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.
Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).
In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.
I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.
llvm-svn: 281277
|
|
tuple-like decomposition declaration. This significantly simplifies the
semantics of BindingDecls for AST consumers (they can now always be evalated
at the point of use).
llvm-svn: 278640
|
|
llvm-svn: 278447
|
|
initializer
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
|
