1. 31 Jan, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r293596: · 1b8468f0
      Hans Wennborg authored
      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.
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@293653 91177308-0d34-0410-b5e6-96231b3b80d8
  2. 23 Jan, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r292555, r292558 and r292559: · 6a36a695
      Hans Wennborg authored
      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
  3. 09 Jan, 2017 3 commits
    • David L. Jones's avatar
      Allow constexpr construction of subobjects unconditionally, not just in C++14. · fb15aef1
      David L. Jones authored
      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
        struct foo_t { union { int i; volatile int j; } u; };
        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; };
        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
    • George Burgess IV's avatar
      Add the diagnose_if attribute to clang. · 5a6ff0d5
      George Burgess IV authored
      `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
      constexpr int bar(int 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
    • Faisal Vali's avatar
      [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions. · 25f75c48
      Faisal Vali authored
      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
  4. 08 Jan, 2017 1 commit
    • Faisal Vali's avatar
      [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the... · 81f1ca9e
      Faisal Vali authored
      [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).
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291397 91177308-0d34-0410-b5e6-96231b3b80d8
  5. 03 Jan, 2017 1 commit
  6. 27 Dec, 2016 1 commit
  7. 23 Dec, 2016 1 commit
  8. 22 Dec, 2016 1 commit
    • George Burgess IV's avatar
      Add the alloc_size attribute to clang, attempt 2. · aa365cb2
      George Burgess IV authored
      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
      - 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
  9. 20 Dec, 2016 4 commits
  10. 15 Dec, 2016 2 commits
  11. 14 Dec, 2016 2 commits
  12. 13 Dec, 2016 1 commit
  13. 12 Dec, 2016 1 commit
    • Richard Smith's avatar
      Add two new AST nodes to represent initialization of an array in terms of · 0601f898
      Richard Smith authored
      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
  14. 09 Dec, 2016 2 commits
    • Yaxun Liu's avatar
      Add support for non-zero null pointer for C and OpenCL · b6215483
      Yaxun Liu authored
      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
    • Richard Smith's avatar
      DR1295 and cleanup for P0135R1: Make our initialization code more directly · b40a34de
      Richard Smith authored
      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
  15. 06 Dec, 2016 1 commit
  16. 05 Dec, 2016 1 commit
    • Richard Smith's avatar
      DR1213: element access on an array xvalue or prvalue produces an xvalue. In the · 88800602
      Richard Smith authored
      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
  17. 29 Nov, 2016 1 commit
  18. 16 Nov, 2016 1 commit
  19. 13 Nov, 2016 1 commit
    • Faisal Vali's avatar
      Fix PR28366: Handle variables from enclosing local scopes more gracefully... · e3fbde74
      Faisal Vali authored
      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
  20. 12 Nov, 2016 1 commit
  21. 11 Nov, 2016 1 commit
  22. 21 Oct, 2016 1 commit
  23. 17 Oct, 2016 1 commit
  24. 08 Oct, 2016 1 commit
  25. 19 Sep, 2016 2 commits
  26. 12 Sep, 2016 1 commit
    • George Burgess IV's avatar
      [Sema] Fix PR30346: relax __builtin_object_size checks. · 6603cadc
      George Burgess IV authored
      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:
      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
  27. 14 Aug, 2016 1 commit
  28. 12 Aug, 2016 1 commit
  29. 28 Jul, 2016 1 commit
    • Yaxun Liu's avatar
      [OpenCL] Generate opaque type for sampler_t and function call for the initializer · 427517d1
      Yaxun Liu authored
      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
  30. 18 Jul, 2016 2 commits