------------------------------------------------------------------------
r293596 | ahatanak | 2017-01-30 18:31:39 -0800 (Mon, 30 Jan 2017) | 7 lines

Handle ObjCEncodeExpr in extractStringLiteralCharacter.

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/branches/release_40@293653 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------
r292555 | rsmith | 2017-01-19 16:45:35 -0800 (Thu, 19 Jan 2017) | 6 lines

P0426: Make the library implementation of constexpr char_traits a little easier
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.

------------------------------------------------------------------------

------------------------------------------------------------------------
r292558 | rsmith | 2017-01-19 16:57:59 -0800 (Thu, 19 Jan 2017) | 2 lines

Add documentation for constexpr string builtin support.

------------------------------------------------------------------------

------------------------------------------------------------------------
r292559 | rsmith | 2017-01-19 17:08:15 -0800 (Thu, 19 Jan 2017) | 2 lines

Fix documentation typo.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@292807 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

[cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the 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!



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 addresses post-review feedback from r290577.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290584 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290431 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

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290171 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289787 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289713 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289647 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

functions, in order to support constexpr std::char_traits<wchar_t>.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288193 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

Fix PR28366: Handle variables from enclosing local scopes more gracefully 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();
}



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286748 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286699 91177308-0d34-0410-b5e6-96231b3b80d8

support constexpr char_traits.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286678 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284856 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284366 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283657 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281923 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278447 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 (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b).

Differential Revision: https://reviews.llvm.org/D21567

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277024 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275925 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

Differential Revision: https://reviews.llvm.org/D20100

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275882 91177308-0d34-0410-b5e6-96231b3b80d8