C++14 [dcl.constexpr]p4 states that in the body of a constexpr
constructor,
> every non-variant non-static data member and base class sub-object
shall be initialized
However, [class.bit]p2 notes that
> Unnamed bit-fields are not members and cannot be initialized.
Therefore, we should make sure to filter them out of the check that
all fields are initialized.
Fixing this makes the constant evaluator a bit smarter, and
specifically allows constexpr constructors to avoid tripping
-Wglobal-constructors when the type contains unnamed bitfields.
Reviewed at https://reviews.llvm.org/D39035.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316408 91177308-0d34-0410-b5e6-96231b3b80d8
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316245 91177308-0d34-0410-b5e6-96231b3b80d8
The standard is not clear on how these are supposed to be handled, so we
conservatively treat as non-constant any cases whose value is unknown or whose
evaluation might result in undefined behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311970 91177308-0d34-0410-b5e6-96231b3b80d8
The fix in r310994 is incomplete, as moveFromAndCancel can set the
pointer without initializing OldIsSpeculativelyEvaluating.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311070 91177308-0d34-0410-b5e6-96231b3b80d8
When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310994 91177308-0d34-0410-b5e6-96231b3b80d8
They are stack allocated, so their alignment is not to be trusted.
32-bit MSVC only guarantees 4 byte stack alignment, even though alignof
would tell you otherwise. I tried fixing this with __declspec align, but
that apparently upsets GCC. Hopefully this version will satisfy all
compilers.
See PR32018 for some info about the mingw issues.
Should supercede https://reviews.llvm.org/D34873
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310905 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r306137 made dllimport pointers to member functions non-constant. This
is correct because a load must be executed to resolve any dllimported
data. However, r306137 did not account for the use of dllimport member
function pointers used as template arguments.
This change re-lands r306137 with a template instantiation fix.
This fixes PR33570.
Reviewers: rnk, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34714
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307446 91177308-0d34-0410-b5e6-96231b3b80d8
Also add testcases for a bunch of expression forms that cause our evaluator to
crash. See PR33140 and PR32864 for crashes that this was causing.
This reverts r305287, which reverted r305239, which reverted r301742. The
previous revert claimed that buildbots were broken, but did not add any
testcases and the buildbots have lost all memory of what was wrong here.
Changes to test/OpenMP are not reverted; another change has triggered those
tests to change their output in the same way that r301742 did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306346 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r306137. It has problems on code like this:
struct __declspec(dllimport) Foo {
int a;
int get_a() { return a; }
};
template <int (Foo::*Getter)()> struct HasValue {
int operator()(Foo *p) { return (p->*Getter)(); }
};
int main() {
Foo f;
f.a = 3;
int x = HasValue<&Foo::get_a>()(&f);
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306175 91177308-0d34-0410-b5e6-96231b3b80d8
We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130. We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.
Fixes PR33570.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306137 91177308-0d34-0410-b5e6-96231b3b80d8
The patch was itself correct but it uncovered other bugs which are going to be difficult to fix, per PR33140.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305233 91177308-0d34-0410-b5e6-96231b3b80d8
We were leaving the SubobjectDesignator in a surprising situation, where
it was allegedly valid but didn't actually refer to a type. This caused
a crash later on.
This patch fills out the SubobjectDesignator with the pointee type (as
happens in other evaluations of constant pointers) so that we don't
crash later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303957 91177308-0d34-0410-b5e6-96231b3b80d8
handling of constexprs with unknown bounds.
This triggers a corner case of the language where it's not yet clear
whether this should be an error:
struct A {
static void *const a[];
static void *const b[];
};
constexpr void *A::a[] = {&b[0]};
constexpr void *A::b[] = {&a[0]};
When discovering the initializer for A::a, the bounds of A::b aren't known yet.
It is unclear whether warning about errors should be deferred until the end of
the translation unit, possibly resolving errors that can be resolved. In
practice, the compiler can know the bounds of all arrays in this example.
Credits for reproducers and explanation go to Richard Smith. Richard, please
add more info in case my explanation is wrong.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301963 91177308-0d34-0410-b5e6-96231b3b80d8
The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301891 91177308-0d34-0410-b5e6-96231b3b80d8
Do not spuriously reject constexpr functions that access elements of an array
of unknown bound; this may later become valid once the bound is known. Permit
array-to-pointer decay on such arrays, but disallow pointer arithmetic (since
we do not know whether it will have defined behavior).
The standard is not clear on how this should work, but this seems to be a
decent answer.
Patch by Robert Haberlach!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301822 91177308-0d34-0410-b5e6-96231b3b80d8
CheckForIntOverflow used to implement a whitelist of top-level expressions to
send to the constant expression evaluator, which handled many more expressions
than the CheckForIntOverflow whitelist did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301742 91177308-0d34-0410-b5e6-96231b3b80d8
A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects.
Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301721 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297276 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297093 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295886 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295311 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295279 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294800 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an assertion failure that occurs later in the function when
an ObjCEncodeExpr is cast to StringLiteral.
rdar://problem/30111207
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293596 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293595 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293568 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293207 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292555 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291480 91177308-0d34-0410-b5e6-96231b3b80d8
`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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291418 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291416 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291397 91177308-0d34-0410-b5e6-96231b3b80d8
I accidentally omitted these when refactoring this code. This caused
problems when building parts of the test-suite on MacOS.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290297 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290173 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290169 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290149 91177308-0d34-0410-b5e6-96231b3b80d8
type differs from the type of the actual function due to having a different
exception specification.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289754 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289575 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289413 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289252 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289250 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288866 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288654 91177308-0d34-0410-b5e6-96231b3b80d8
common case of a call to a non-builtin, particularly for unoptimized ASan
builds (where the per-variable stack usage can be quite high).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@287066 91177308-0d34-0410-b5e6-96231b3b80d8
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();
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286748 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281907 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281277 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278640 91177308-0d34-0410-b5e6-96231b3b80d8
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 (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277024 91177308-0d34-0410-b5e6-96231b3b80d8
if (stmt; condition) { ... }
Patch by Anton Bikineev! Some minor formatting and comment tweets by me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275350 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, we have CCEDiags (C++11 core constant expression diags) and Fold failure diagnostics [I don't claim to yet fully understand exactly why we need the difference]. This patch explicitly replaces Info.Diag (whose use always represents a fold failure diag within the file) with Info.FFDiag. This makes it more easily greppable in the file, and just like the name Info.CCEDiag, it gives the reader slight further insight into the nature of the diagnostic (as opposed to Info.Diag).
This patch is a preliminary refactoring step in an effort to allow support for compatibility-warnings and extensions (such as constexpr lambda) during constant expression evaluation.
All regressions pass.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274454 91177308-0d34-0410-b5e6-96231b3b80d8
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a crash in code like:
```
struct A {
struct B b;
char c[1];
}
int foo(struct A* a) { return __builtin_object_size(a->c, 0); }
```
We wouldn't check whether the structs we were examining were invalid,
and getting the layout of an invalid struct is (unsurprisingly) A Bad
Thing. With this patch, we'll always return conservatively if we see an
invalid struct, since I'm assuming the presence of an invalid struct
means that our compilation failed (so having a conservative result isn't
such a big deal).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273911 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
OpenCL should support array with const value size length, those const
varibale in global and constant address space and variable in constant
address space.
Fixed test case error.
Reviewers: Anastasia, yaxunl, bader
Subscribers: bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D20090
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271978 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
OpenCL should support array with const value size length, those const varibale in global and constant address space and variable in constant address space.
Reviewers: Anastasia, yaxunl, bader
Subscribers: bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D20090
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271971 91177308-0d34-0410-b5e6-96231b3b80d8
We would attempt to evaluate the sizeof a dependent type to check for an
integral overflow. However, because the dependent type is not yet resolved, we
cannot determine if the expression would overflow. Report a failure to perform
a symbolic evaluation of a constant involving the dependent type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271762 91177308-0d34-0410-b5e6-96231b3b80d8
r270781 introduced the ability to track whether or not we might have
had unmodeled side-effects during constant expression evaluation. This
patch makes the constexpr evaluator use that tracking.
Reviewed as a part of D18540.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270784 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, the constexpr evaluator is very conservative about unmodeled
side-effects when we're evaluating an expression in a mode that allows
such side-effects.
This patch makes us note when we might have actually encountered an
unmodeled side-effect, which allows us to be more accurate when we know
an unmodeled side-effect couldn't have occurred.
This patch has been split into two commits; this one primarily
introduces the bits necessary to track whether we might have potentially
hit such a side-effect. The one that actually does the tracking (which
boils down to more or less a rename of keepEvaluatingAfterFailure to
noteFailure) is coming soon.
Differential Revision: http://reviews.llvm.org/D18540
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270781 91177308-0d34-0410-b5e6-96231b3b80d8
const' variable. That variable might be defined as 'constexpr', so we cannot
prove that a use of it could never be a constant expression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270774 91177308-0d34-0410-b5e6-96231b3b80d8
Restructure the implict floating point to integer conversions so that
interesting sub-groups are under different flags. Breakdown of warnings:
No warning:
Exact conversions from floating point to integer:
int x = 10.0;
int x = 1e10;
-Wliteral-conversion - Floating point literal to integer with rounding:
int x = 5.5;
int x = -3.4;
-Wfloat-conversion - All conversions not covered by the above two:
int x = GetFloat();
int x = 5.5 + 3.5;
-Wfloat-zero-conversion - The expression converted has a non-zero floating
point value that gets converted to a zero integer value, excluded the cases
falling under -Wliteral-conversion. Subset of -Wfloat-conversion.
int x = 1.0 / 2.0;
-Wfloat-overflow-conversion - The floating point value is outside the range
of the integer type, exluding cases from -Wliteral conversion. Subset of
-Wfloat-conversion.
char x = 500;
char x = -1000;
-Wfloat-bool-conversion - Any conversion of a floating point type to bool.
Subset of -Wfloat-conversion.
if (GetFloat()) {}
bool x = 5.0;
-Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable
floating point value to bool. Subset of -Wfloat-bool-conversion.
bool x = 1.0;
bool x = 4.0 / 20.0;
Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for
floating point values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267054 91177308-0d34-0410-b5e6-96231b3b80d8
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.
Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266180 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith