Commit Graph

304 Commits

Author SHA1 Message Date
Richard Smith 902a0238aa DR1748: the reserved placement allocation functions have undefined behavior if
they're given a null pointer as an argument, so we do not need to emit null
checks on their results.

llvm-svn: 229213
2015-02-14 01:52:20 +00:00
David Blaikie 9b47966615 DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.

There were essentially 3 options for this:

* The beginning of an expression (this was the behavior prior to this
  commit). This meant that stepping through subexpressions would bounce
  around from subexpressions back to the start of the outer expression,
  etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
  where the actual addition occurred)).

* The end of an expression. This seems to be what GCC does /mostly/, and
  certainly this for function calls. This has the advantage that
  progress is always 'forwards' (never jumping backwards - except for
  independent subexpressions if they're evaluated in interesting orders,
  etc). "x + y + z" would go "x y z" with the additions occurring at y
  and z after the respective loads.
  The problem with this is that the user would still have to think
  fairly hard about precedence to realize which subexpression is being
  evaluated or which operator overload is being called in, say, an asan
  backtrace.

* The preferred location or 'exprloc'. In this case you get sort of what
  you'd expect, though it's a bit confusing in its own way due to going
  'backwards'. In this case the locations would be: "x y + z +" in
  lovely postfix arithmetic order. But this does mean that if the op+
  were an operator overload, say, and in a backtrace, the backtrace will
  point to the exact '+' that's being called, not to the end of one of
  its operands.

(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)

llvm-svn: 227027
2015-01-25 01:19:10 +00:00
David Blaikie 66e4197f07 Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).
Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225956
2015-01-14 07:38:27 +00:00
David Blaikie f353d3ecd0 Revert "DebugInfo: Generalize debug info location handling" and related commits
This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.

I'll work up some test cases and fixes before recommitting this.

llvm-svn: 225555
2015-01-09 23:00:28 +00:00
David Blaikie 84fe79cfc3 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000
2014-12-30 19:39:33 +00:00
David Blaikie 608a24501c Revert "DebugInfo: Generalize debug info location handling"
Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970
2014-12-29 23:49:00 +00:00
David Blaikie 3945d1bd99 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224941
2014-12-29 18:18:45 +00:00
David Blaikie 06b2c54db9 Revert "DebugInfo: Generalize debug info location handling"
Fails an ASan bootstrap - I'll try to reproduce locally & sort that out
before recommitting.

This reverts commit r224385.

llvm-svn: 224441
2014-12-17 18:02:04 +00:00
David Blaikie bf22a4eaee DebugInfo: Generalize debug info location handling
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224385
2014-12-16 22:49:17 +00:00
David Blaikie 09f12fa1ca DebugInfo: More accurate line information for placement new.
This actually came up as a break in UBSan tests (look for a follow-up
commit to this one to see the UBSan test fallout) when I tried a broader
fix to location information.

I have some other ideas about how to do that broader change & will keep
looking into it.

llvm-svn: 224221
2014-12-14 18:48:18 +00:00
Peter Collingbourne f770683f14 Implement the __builtin_call_with_static_chain GNU extension.
The extension has the following syntax:

  __builtin_call_with_static_chain(Call, Chain)
  where Call must be a function call expression and Chain must be of pointer type

This extension performs a function call Call with a static chain pointer
Chain passed to the callee in a designated register. This is useful for
calling foreign language functions whose ABI uses static chain pointers
(e.g. to implement closures).

Differential Revision: http://reviews.llvm.org/D6332

llvm-svn: 224167
2014-12-12 23:41:25 +00:00
David Blaikie a2c1124f9c DebugInfo: Location information for scalar new expressions
llvm-svn: 223937
2014-12-10 19:04:09 +00:00
David Blaikie d73f3c6b73 DebugInfo: Correct location of aggregate assignment
llvm-svn: 223854
2014-12-09 23:33:26 +00:00
Nico Weber aad4af6d50 Fix incorrect codegen for devirtualized calls to virtual overloaded operators.
Consider this program:

    struct A {
      virtual void operator-() { printf("base\n"); }
    };
    struct B final : public A {
      virtual void operator-() override { printf("derived\n"); }
    };

    int main() {
      B* b = new B;
      -static_cast<A&>(*b);
    }

Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable.  Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.

For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.

This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.

This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.

(This adjustment for virtual operator calls seems still wrong with the MS ABI.)

llvm-svn: 223185
2014-12-03 01:21:41 +00:00
Nico Weber 3abfe95843 Wrap to 80 columns. No behavior change.
llvm-svn: 223149
2014-12-02 20:41:18 +00:00
Kostya Serebryany 4133eabb45 [clang/asan] Do not emit memcpy for trivial operator= when -fsanitize-address-field-padding >= 1
Summary: If we've added poisoned paddings to a type do not emit memcpy for operator=.

Test Plan: regression tests.

Reviewers: majnemer, rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6160

llvm-svn: 221739
2014-11-11 23:38:13 +00:00
David Majnemer 0868137ac8 CodeGen: Declutter the emitVirtualObjectDelete interface
No functionality change intended.

llvm-svn: 221043
2014-11-01 07:37:17 +00:00
David Majnemer 0c0b6d9ac6 MS ABI: Properly call global delete when invoking virtual destructors
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.

Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
  flag" set.  The virtual deleting destructor will return a pointer to
  'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.

Reviewers: rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D5996

llvm-svn: 220993
2014-10-31 20:09:12 +00:00
Alexey Bataev 5bd6879439 Fix bug 20116 - http://llvm.org/bugs/show_bug.cgi?id=20116
Fixes incorrect codegen when devirtualization is aborted due to covariant return types.

Differential Revision: http://reviews.llvm.org/D5321

llvm-svn: 218602
2014-09-29 10:32:21 +00:00
Rafael Espindola 1ac0ec86b7 Merge GetAddrOfCXXConstructor and GetAddrOfCXXDonstructor. NFC.
llvm-svn: 217598
2014-09-11 15:42:06 +00:00
Alexey Samsonov 8e1162c71d Implement nonnull-attribute sanitizer
Summary:
This patch implements a new UBSan check, which verifies
that function arguments declared to be nonnull with __attribute__((nonnull))
are actually nonnull in runtime.

To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs
(where applicable) and if function declaration has nonnull attribute specified
for a certain formal parameter, we compare the corresponding RValue to null as
soon as it's calculated.

Test Plan: regression test suite

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, rnk

Differential Revision: http://reviews.llvm.org/D5082

llvm-svn: 217389
2014-09-08 17:22:45 +00:00
Rafael Espindola 8d2a19b478 Handle constructors and destructors a bit more uniformly in CodeGen.
There were code paths that are duplicated for constructors and destructors just
because we have both CXXCtorType and CXXDtorsTypes.

This patch introduces an unified enum and reduces code deplication a bit.

llvm-svn: 217383
2014-09-08 16:01:27 +00:00
Aaron Ballman 455f42c9e8 Reverting r216675. This breaks some bots. Before this can be committed again, I have to explore runtime ABI requirements with libc++abi.
llvm-svn: 216677
2014-08-28 17:24:14 +00:00
Aaron Ballman 33375375a4 Throw a std::bad_array_new_length exception when the expression (or constant-expression) passed to operator new[] results in overflow in conformance with [expr.new]p7. Fixes PR11644.
llvm-svn: 216675
2014-08-28 16:48:44 +00:00
Alexey Bataev 39c81e2816 [C++11] Support for capturing of variable length arrays in lambda expression.
Differential Revision: http://reviews.llvm.org/D4368

llvm-svn: 216649
2014-08-28 04:28:19 +00:00
Alexey Samsonov cbe875a507 Kill one of EmitCallArgs overloads. NFC.
llvm-svn: 216635
2014-08-28 00:22:11 +00:00
Alexey Samsonov 525bf650cc Pass actual CXXConstructExpr instead of argument iterators
into EmitSynthesizedCXXCopyCtorCall. No functionality change.

llvm-svn: 216410
2014-08-25 21:58:56 +00:00
Alexey Samsonov a5bf76bdf3 Pass actual CallExpr instead of CallExpr-specific iterators
into EmitCXXMemberOrOperatorCall methods. In the end we want
to make declaration visible in EmitCallArgs() method, that
would allow us to alter CodeGen depending on function/parameter
attributes.

No functionality change.

llvm-svn: 216404
2014-08-25 20:17:35 +00:00
Alexey Samsonov 70b9c01bd4 Pass expressions instead of argument ranges to EmitCall/EmitCXXConstructorCall.
Summary:
This is a first small step towards passing generic "Expr" instead of
ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will
allow us to get the corresponding FunctionDecl and its ParmVarDecls,
thus allowing us to alter CodeGen depending on the function/parameter
attributes.

No functionality change.

Test Plan: regression test suite

Reviewers: rnk

Reviewed By: rnk

Subscribers: aemerson, cfe-commits

Differential Revision: http://reviews.llvm.org/D4915

llvm-svn: 216214
2014-08-21 20:26:47 +00:00
David Majnemer 1c3d95ebc5 CodeGen: Properly null-check typeid expressions
Thoroughly check for a pointer dereference which yields a glvalue.  Look
through casts, comma operators, conditional operators, paren
expressions, etc.

This was originally D4416.

Differential Revision: http://reviews.llvm.org/D4592

llvm-svn: 213434
2014-07-19 00:17:06 +00:00
David Majnemer 9edaf7c822 Revert "CodeGen: Properly null-check typeid expressions"
This reverts commit r213401, r213402, r213403, and r213404.

I accidently committed these changes instead of updating the
differential.

llvm-svn: 213405
2014-07-18 20:00:13 +00:00
David Majnemer 5dd5ea422a Address Richard's latest feedback.
llvm-svn: 213404
2014-07-18 19:53:25 +00:00
David Majnemer e04c470afa Address Richard's comments
llvm-svn: 213403
2014-07-18 19:53:23 +00:00
David Majnemer 18a9ac9129 Address Richard's comments.
llvm-svn: 213402
2014-07-18 19:53:21 +00:00
David Majnemer 4fbb1b9f98 CodeGen: Properly null-check typeid expressions
Summary:
Thoroughly check for a pointer dereference which yields a glvalue.  Look
through casts, comma operators, conditional operators, paren
expressions, etc.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D4416

llvm-svn: 213401
2014-07-18 19:53:17 +00:00
David Majnemer 1162d25c1b Revert "Revert r211402 (and r211408,r211410), "CodeGen: Refactor dynamic_cast and typeid" It crashes msvc codegen in clang/test/SemaCXX/undefined-internal.cpp."
This reverts commit r211467 which reverted r211408,r211410, it caused
crashes in test/SemaCXX/undefined-internal.cpp for i686-win32 targets.

llvm-svn: 211473
2014-06-22 19:05:33 +00:00
NAKAMURA Takumi 0a6c5e2fb5 Revert r211402 (and r211408,r211410), "CodeGen: Refactor dynamic_cast and typeid" It crashes msvc codegen in clang/test/SemaCXX/undefined-internal.cpp.
It is reproducible with:

  $ clang -cc1 -triple i686-win32 -emit-llvm-only clang/test/SemaCXX/undefined-internal.cpp

llvm-svn: 211467
2014-06-22 12:42:29 +00:00
David Majnemer f1c9cbc2a2 CodeGen: Refactor dynamic_cast and typeid
This refactors the emission of dynamic_cast and typeid expressions so
that ABI specific knowledge lives in appropriate places.  There are
quite a few benefits for having the two implementations share a common
core like sharing logic for optimization opportunities.

While we are at it, clean up the tests.

llvm-svn: 211402
2014-06-20 21:11:00 +00:00
Warren Hunt 747e301ea0 [MS-ABI] Implement typeid
This patch enables clang to generate calls to __RTtypeid when lowering 
typeid on win32 targets.  Test cases are included.

llvm-svn: 211223
2014-06-18 21:15:55 +00:00
Alp Toker 233b372831 Fix typos
llvm-svn: 211025
2014-06-16 14:23:44 +00:00
Warren Hunt b57b4b098c [MS-ABI] Implement dynamic_cast
This patch implements call lower from dynamic_cast to __RTDynamicCast 
and __RTCastToVoid.  Test cases are included.  A feature of note is that 
helper function getPolymorphicOffset is placed in such a way that it can 
be used by EmitTypeid (to be implemented in a later patch) without being 
moved.  Details are included as comments directly in the code.

llvm-svn: 210377
2014-06-06 22:12:37 +00:00
Richard Smith 599bed75ed Bugfix: don't assert if someone manages to declare an operator new/delete template before the builtin operator new/delete.
llvm-svn: 210230
2014-06-05 00:43:02 +00:00
Richard Smith 760520bcb7 Add __builtin_operator_new and __builtin_operator_delete, which act like calls
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.

llvm-svn: 210137
2014-06-03 23:27:44 +00:00
Richard Smith 454a7cdfb3 Implement DR990 and DR1070. Aggregate initialization initializes uninitialized
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)

llvm-svn: 210091
2014-06-03 08:26:00 +00:00
Richard Smith 06a67e2c6f When emitting a multidimensional array new, emit the initializers for the
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.

llvm-svn: 210079
2014-06-03 06:58:52 +00:00
Craig Topper 8a13c4180e [C++11] Use 'nullptr'. CodeGen edition.
llvm-svn: 209272
2014-05-21 05:09:00 +00:00
Chandler Carruth e6c980c41d [leaks] Re-shuffle code such that we don't create a basic block for
initializing an array unless we need it. Specifically, position the
creation of a new basic block after we've checked all of the cases that
bypass the need for it.

Fixes another leak in test/CodeGen* found by LSan.

llvm-svn: 207900
2014-05-03 09:16:57 +00:00
Timur Iskhodzhanov f1749427c5 Fix PR19104: Incorrect handling of non-virtual calls of virtual methods
Reviewed at http://llvm-reviews.chandlerc.com/D3054

llvm-svn: 203949
2014-03-14 17:43:37 +00:00
Craig Topper 4f12f10de4 [C++11] Add 'override' keyword to virtual methods that override their base class.
llvm-svn: 203643
2014-03-12 06:41:41 +00:00
Chandler Carruth c80ceea90b [Modules] Update to reflect the move of CallSite into the IR library in
LLVM r202816.

llvm-svn: 202817
2014-03-04 11:02:08 +00:00