1. 27 Jan, 2017 1 commit
    • Hans Wennborg's avatar
      Merging r292590: · 2d09298b
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r292590 | abataev | 2017-01-20 00:57:28 -0800 (Fri, 20 Jan 2017) | 6 lines
      
      [OPENMP] Fix for PR31643: Clang crashes when compiling code on Windows
      with SEH and openmp
      
      In some cituations (during codegen for Windows SEH constructs)
      CodeGenFunction instance may have CurFn equal to nullptr. OpenMP related
      code does not expect such situation during cleanup.
      ------------------------------------------------------------------------
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_40@293302 91177308-0d34-0410-b5e6-96231b3b80d8
      2d09298b
  2. 06 Jan, 2017 1 commit
  3. 04 Jan, 2017 1 commit
    • Alex Lorenz's avatar
      Add -f[no-]strict-return flag that can be used to avoid undefined behaviour · 8fca6cf5
      Alex Lorenz authored
      in non-void functions that fall off at the end without returning a value when
      compiling C++.
      
      Clang uses the new compiler flag to determine when it should treat control flow
      paths that fall off the end of a non-void function as unreachable. If
      -fno-strict-return is on, the code generator emits the ureachable and trap
      IR only when the function returns either a record type with a non-trivial
      destructor or another non-trivially copyable type.
      
      The primary goal of this flag is to avoid treating falling off the end of a
      non-void function as undefined behaviour. The burden of undefined behaviour
      is placed on the caller instead: if the caller ignores the returned value then
      the undefined behaviour is avoided. This kind of behaviour is useful in
      several cases, e.g. when compiling C code in C++ mode.
      
      rdar://13102603
      
      Differential Revision: https://reviews.llvm.org/D27163
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290960 91177308-0d34-0410-b5e6-96231b3b80d8
      8fca6cf5
  4. 23 Dec, 2016 1 commit
    • Chandler Carruth's avatar
      Cleanup the handling of noinline function attributes, -fno-inline, · d0ca1639
      Chandler Carruth authored
      -fno-inline-functions, -O0, and optnone.
      
      These were really, really tangled together:
      - We used the noinline LLVM attribute for -fno-inline
        - But not for -fno-inline-functions (breaking LTO)
        - But we did use it for -finline-hint-functions (yay, LTO is happy!)
        - But we didn't for -O0 (LTO is sad yet again...)
      - We had weird structuring of CodeGenOpts with both an inlining
        enumeration and a boolean. They interacted in weird ways and
        needlessly.
      - A *lot* of set smashing went on with setting these, and then got worse
        when we considered optnone and other inlining-effecting attributes.
      - A bunch of inline affecting attributes were managed in a completely
        different place from -fno-inline.
      - Even with -fno-inline we failed to put the LLVM noinline attribute
        onto many generated function definitions because they didn't show up
        as AST-level functions.
      - If you passed -O0 but -finline-functions we would run the normal
        inliner pass in LLVM despite it being in the O0 pipeline, which really
        doesn't make much sense.
      - Lastly, we used things like '-fno-inline' to manipulate the pass
        pipeline which forced the pass pipeline to be much more
        parameterizable than it really needs to be. Instead we can *just* use
        the optimization level to select a pipeline and control the rest via
        attributes.
      
      Sadly, this causes a bunch of churn in tests because we don't run the
      optimizer in the tests and check the contents of attribute sets. It
      would be awesome if attribute sets were a bit more FileCheck friendly,
      but oh well.
      
      I think this is a significant improvement and should remove the semantic
      need to change what inliner pass we run in order to comply with the
      requested inlining semantics by relying completely on attributes. It
      also cleans up tho optnone and related handling a bit.
      
      One unfortunate aspect of this is that for generating alwaysinline
      routines like those in OpenMP we end up removing noinline and then
      adding alwaysinline. I tried a bunch of other approaches, but because we
      recompute function attributes from scratch and don't have a declaration
      here I couldn't find anything substantially cleaner than this.
      
      Differential Revision: https://reviews.llvm.org/D28053
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290398 91177308-0d34-0410-b5e6-96231b3b80d8
      d0ca1639
  5. 12 Dec, 2016 1 commit
    • Filipe Cabecinhas's avatar
      [clang] Version support for UBSan handlers · 19350fe2
      Filipe Cabecinhas authored
      This adds a way for us to version any UBSan handler by itself.
      The patch overrides D21289 for a better implementation (we're able to
      rev up a single handler).
      
      After this, then we can land a slight modification of D19667+D19668.
      
      We probably don't want to keep all the versions in compiler-rt (maybe we
      want to deprecate on one release and remove the old handler on the next
      one?), but with this patch we will loudly fail to compile when mixing
      incompatible handler calls, instead of silently compiling and then
      providing bad error messages.
      
      Reviewers: kcc, samsonov, rsmith, vsk
      
      Subscribers: cfe-commits
      
      Differential Revision: https://reviews.llvm.org/D21695
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289444 91177308-0d34-0410-b5e6-96231b3b80d8
      19350fe2
  6. 14 Nov, 2016 1 commit
  7. 11 Nov, 2016 1 commit
    • Anna Zaks's avatar
      [tsan][clang] Introduce a function attribute to disable TSan checking at run time · f05b16b9
      Anna Zaks authored
      This introduces a function annotation that disables TSan checking for the
      function at run time. The benefit over attribute((no_sanitize("thread")))
      is that the accesses within the callees will also be suppressed.
      
      The motivation for this attribute is a guarantee given by the objective C
      language that the calls to the reference count decrement and object
      deallocation will be synchronized. To model this properly, we would need to
      intercept all ref count decrement calls (which are very common in ObjC due
      to use of ARC) and also every single message send. Instead, we propose to
      just ignore all accesses made from within dealloc at run time. The main
      downside is that this still does not introduce any synchronization, which
      means we might still report false positives if the code that relies on this
      synchronization is not executed from within dealloc. However, we have not
      seen this in practice so far and think these cases will be very rare.
      
      (This problem is similar in nature to https://reviews.llvm.org/D21609;
      unfortunately, the same solution does not apply here.)
      
      Differential Revision: https://reviews.llvm.org/D25857
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286672 91177308-0d34-0410-b5e6-96231b3b80d8
      f05b16b9
  8. 10 Nov, 2016 1 commit
  9. 26 Oct, 2016 2 commits
  10. 16 Sep, 2016 1 commit
    • Richard Smith's avatar
      Fix a couple of wrong-code bugs in switch-on-constant optimization: · 550a211f
      Richard Smith authored
       * recurse through intermediate LabelStmts and AttributedStmts when checking
         whether a statement inside a switch declares a variable
       * if the end of a compound statement is reachable from the chosen case label,
         and the compound statement contains a variable declaration, it's not valid
         to just emit the contents of the compound statement -- we must emit the
         statement itself or we lose the scope (and thus end lifetimes at the wrong
         point)
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281797 91177308-0d34-0410-b5e6-96231b3b80d8
      550a211f
  11. 13 Sep, 2016 2 commits
  12. 06 Sep, 2016 1 commit
  13. 01 Sep, 2016 2 commits
  14. 13 Jul, 2016 2 commits
  15. 28 Jun, 2016 1 commit
    • Richard Smith's avatar
      P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991: · 5be817d9
      Richard Smith authored
      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
      5be817d9
  16. 24 Jun, 2016 1 commit
  17. 23 Jun, 2016 1 commit
  18. 22 Jun, 2016 2 commits
  19. 08 Jun, 2016 1 commit
    • Reid Kleckner's avatar
      [DebugInfo] Add calling conventions to DISubroutineType · bb80708b
      Reid Kleckner authored
      Summary:
      This should have been a very simple change, but it was greatly
      complicated by the construction of new Decls during IR generation.
      
      In particular, we reconstruct the AST function type in order to get the
      implicit 'this' parameter into C++ method types.
      
      We also have to worry about FunctionDecls whose types are not
      FunctionTypes because CGBlocks.cpp constructs some dummy FunctionDecls
      with 'void' type.
      
      Depends on D21114
      
      Reviewers: aprantl, dblaikie
      
      Subscribers: cfe-commits
      
      Differential Revision: http://reviews.llvm.org/D21141
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272198 91177308-0d34-0410-b5e6-96231b3b80d8
      bb80708b
  20. 06 May, 2016 1 commit
  21. 28 Apr, 2016 1 commit
  22. 19 Apr, 2016 1 commit
  23. 08 Apr, 2016 2 commits
  24. 07 Apr, 2016 1 commit
  25. 05 Apr, 2016 1 commit
  26. 21 Mar, 2016 1 commit
    • Faisal Vali's avatar
      [Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3) · 60783472
      Faisal Vali authored
      Implement lambda capture of *this by copy.
      For e.g.:
      struct A {
      
        int d = 10;
        auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }
      
      };
      
      auto L = A{}.foo(); // A{}'s lifetime is gone.
      
      // Below is still ok, because *this was captured by value.
      assert(L(10) == 20);
      assert(L(100) == 120);
      
      If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.
      
      Implementation Strategy:
        - amend the parser to accept *this in the lambda introducer
        - add a new king of capture LCK_StarThis
        - teach Sema::CheckCXXThisCapture to handle by copy captures of the
          enclosing object (i.e. *this)
        - when CheckCXXThisCapture does capture by copy, the corresponding 
          initializer expression for the closure's data member 
          direct-initializes it thus making a copy of '*this'.
        - in codegen, when assigning to CXXThisValue, if *this was captured by 
          copy, make sure it points to the corresponding field member, and
          not, unlike when captured by reference, what the field member points
          to.
        - mark feature as implemented in svn
      
      Much gratitude to Richard Smith for his carefully illuminating reviews!   
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263921 91177308-0d34-0410-b5e6-96231b3b80d8
      60783472
  27. 13 Mar, 2016 1 commit
  28. 12 Mar, 2016 1 commit
  29. 11 Mar, 2016 1 commit
  30. 01 Mar, 2016 1 commit
  31. 26 Feb, 2016 1 commit
  32. 04 Feb, 2016 1 commit
  33. 02 Feb, 2016 1 commit
  34. 16 Jan, 2016 1 commit