Skip to content
GitLab
  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
  3. 06 Jan, 2017 1 commit
  5. 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
  7. 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
  9. 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
  11. 14 Nov, 2016 1 commit
  13. 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
  15. 10 Nov, 2016 1 commit
  17. 26 Oct, 2016 2 commits
  19. 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
  21. 13 Sep, 2016 2 commits
  23. 06 Sep, 2016 1 commit
  25. 01 Sep, 2016 2 commits
  27. 13 Jul, 2016 2 commits
  29. 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
  31. 24 Jun, 2016 1 commit
  33. 23 Jun, 2016 1 commit
  35. 22 Jun, 2016 2 commits
  37. 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
  39. 06 May, 2016 1 commit
  41. 28 Apr, 2016 1 commit
  43. 19 Apr, 2016 1 commit
  45. 08 Apr, 2016 2 commits
  47. 07 Apr, 2016 1 commit
  49. 05 Apr, 2016 1 commit
  51. 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
  53. 13 Mar, 2016 1 commit
  55. 12 Mar, 2016 1 commit
  57. 11 Mar, 2016 1 commit
  59. 01 Mar, 2016 1 commit
  61. 26 Feb, 2016 1 commit
  63. 04 Feb, 2016 1 commit
  65. 02 Feb, 2016 1 commit
  67. 16 Jan, 2016 1 commit