summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+1
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
* EmitCXXStructorCall -> EmitCXXDestructorCall. NFC.Alexey Samsonov2016-03-101-7/+7
| | | | | | | This function is only used in Microsoft ABI and only to emit destructors. Rename/simplify it accordingly. llvm-svn: 263081
* Remove unused function arguments. NFC.Alexey Samsonov2016-03-101-8/+8
| | | | llvm-svn: 263080
* P0017R1: In C++1z, an aggregate class can have (public non-virtual) base ↵Richard Smith2016-03-081-5/+8
| | | | | | classes; these are initialized as if they were data members. llvm-svn: 262963
* Add whole-program vtable optimization feature to Clang.Peter Collingbourne2016-02-241-1/+2
| | | | | | | | | This patch introduces the -fwhole-program-vtables flag, which enables the whole-program vtable optimization feature (D16795) in Clang. Differential Revision: http://reviews.llvm.org/D16821 llvm-svn: 261767
* [MS ABI] Tolerate invokes of __RTDynamicCastDavid Majnemer2015-11-231-0/+1
| | | | | | | | | | | | The pointer returned by __RTDynamicCast must be bitcasted. However, it was not expected that __RTDynamicCast would be invoked, resulting in the bitcast occuring in a different BasicBlock than the invoke. This caused a down-stream PHI to get confused about which BasicBlock the incomming value was from. This fixes PR25606. llvm-svn: 253843
* Remove unused #includeDavid Majnemer2015-11-031-1/+0
| | | | | | No functionality change is intended. llvm-svn: 251941
* [MS ABI] Don't zero-initialize vbptrs in basesDavid Majnemer2015-11-021-14/+56
| | | | | | | | | | | | Certain CXXConstructExpr nodes require zero-initialization before a constructor is called. We had a bug in the case where the constructor is called on a virtual base: we zero-initialized the base's vbptr field. A complementary bug is present in MSVC where no zero-initialization occurs for the subobject at all. This fixes PR25370. llvm-svn: 251783
* Define weak and __weak to mean ARC-style weak references, even in MRC.John McCall2015-10-221-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, __weak was silently accepted and ignored in MRC mode. That makes this a potentially source-breaking change that we have to roll out cautiously. Accordingly, for the time being, actual support for __weak references in MRC is experimental, and the compiler will reject attempts to actually form such references. The intent is to eventually enable the feature by default in all non-GC modes. (It is, of course, incompatible with ObjC GC's interpretation of __weak.) If you like, you can enable this feature with -Xclang -fobjc-weak but like any -Xclang option, this option may be removed at any point, e.g. if/when it is eventually enabled by default. This patch also enables the use of the ARC __unsafe_unretained qualifier in MRC. Unlike __weak, this is being enabled immediately. Since variables are essentially __unsafe_unretained by default in MRC, the only practical uses are (1) communication and (2) changing the default behavior of by-value block capture. As an implementation matter, this means that the ObjC ownership qualifiers may appear in any ObjC language mode, and so this patch removes a number of checks for getLangOpts().ObjCAutoRefCount that were guarding the processing of these qualifiers. I don't expect this to be a significant drain on performance; it may even be faster to just check for these qualifiers directly on a type (since it's probably in a register anyway) than to do N dependent loads to grab the LangOptions. rdar://9674298 llvm-svn: 251041
* [DEBUG INFO] Emit debug info for type used in explicit cast only.Alexey Bataev2015-10-201-0/+1
| | | | | | | Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug. Differential Revision: http://reviews.llvm.org/D13582 llvm-svn: 250795
* Don't crash when a reserved global placement operator new is pairedJohn McCall2015-09-291-2/+12
| | | | | | with a non-reserved operator delete in a new-expression. llvm-svn: 248862
* Decorating vptr load & stores with !invariant.groupPiotr Padlewski2015-09-151-1/+1
| | | | | | | | | | Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12026 llvm-svn: 247725
* Emiting llvm.invariant.group.barrier when dynamic type changesPiotr Padlewski2015-09-151-0/+8
| | | | | | | | | For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12312 llvm-svn: 247723
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-130/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* Devirtualize EHScopeStack::Cleanup's dtor because it's never destroyed ↵David Blaikie2015-08-181-4/+4
| | | | | | polymorphically llvm-svn: 245378
* Pass an iterator range to EmitCallArgsDavid Blaikie2015-07-211-5/+5
| | | | llvm-svn: 242824
* [AST] Cleanup ExprIterator.Benjamin Kramer2015-07-181-3/+2
| | | | | | | | - Make it a proper random access iterator with a little help from iterator_adaptor_base - Clean up users of magic dereferencing. The iterator should behave like an Expr **. - Make it an implementation detail of Stmt. This allows inlining of the assertions. llvm-svn: 242608
* Fix alignment issues in Clang.James Y Knight2015-07-171-2/+2
| | | | | | | | | | | | | | | | | Some const-correctness changes snuck in here too, since they were in the area of code I was modifying. This seems to make Clang actually work without Bus Error on 32bit-sparc. Follow-up patches will factor out a trailing-object helper class, to make classes using the idiom of appending objects to other objects easier to understand, and to ensure (with static_assert) that required alignment guarantees continue to hold. Differential Revision: http://reviews.llvm.org/D10272 llvm-svn: 242554
* [MS ABI] Workaround corner-case bug in the ABI for operator deleteDavid Majnemer2015-06-301-1/+2
| | | | | | | | | | | | | | | MSVC only genreates array cookies if the class has a destructor. This is problematic when having to call T::operator delete[](void *, size_t) because the second argument's argument is impossible to synthesize correctly if the class has no destructor (because there will be no array cookie). Instead, MSVC passes the size of the class. Do the same, for compatibility, instead of crashing. This fixes PR23990. llvm-svn: 241038
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-3/+3
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-3/+3
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-2/+3
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* Implementing C99 partial re-initialization behavior (DR-253)Yunzhong Gao2015-06-101-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Based on previous discussion on the mailing list, clang currently lacks support for C99 partial re-initialization behavior: Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm This patch attempts to fix this problem. Given the following code snippet, struct P1 { char x[6]; }; struct LP1 { struct P1 p1; }; struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' }; // this example is adapted from the example for "struct fred x[]" in DR-253; // currently clang produces in l: { "\0\0x" }, // whereas gcc 4.8 produces { "fox" }; // with this fix, clang will also produce: { "fox" }; Differential Review: http://reviews.llvm.org/D5789 llvm-svn: 239446
* API update for streamlining of IRBuilder::CreateCall to just use ↵David Blaikie2015-05-181-2/+2
| | | | | | ArrayRef/initializer_list+braced init llvm-svn: 237625
* PR23373: A defaulted union copy constructor that is not trivial must still beRichard Smith2015-04-291-1/+1
| | | | | | emitted as a memcpy. llvm-svn: 236142
* [opaque pointer type] more GEP API migrationsDavid Blaikie2015-04-041-16/+15
| | | | llvm-svn: 234097
* Implement CFI type checks for non-virtual calls.Peter Collingbourne2015-04-021-0/+6
| | | | | | | | | | | | This uses the same class metadata currently used for virtual call and cast checks. The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr flag has been renamed -fsanitize=cfi-vcall. Differential Revision: http://reviews.llvm.org/D8756 llvm-svn: 233874
* Revert "Improvement on sized deallocation from r230160"Reid Kleckner2015-03-191-82/+5
| | | | | | | | | This reverts commit r230580. extern_weak functions don't appear to work on Darwin (PR22951), so we'll need to come up with a new approach. llvm-svn: 232731
* Improvement on sized deallocation from r230160:Larisse Voufo2015-02-251-5/+82
| | | | | | Do not declare sized deallocation functions dependently on whether it is found in global scope. Instead, enforce the branching in emitted code by (1) declaring the functions extern_weak and (2) emitting sized delete expressions as a branching between both forms delete. llvm-svn: 230580
* DR1748: the reserved placement allocation functions have undefined behavior ifRichard Smith2015-02-141-3/+2
| | | | | | | they're given a null pointer as an argument, so we do not need to emit null checks on their results. llvm-svn: 229213
* DebugInfo: Use the preferred location rather than the start location for ↵David Blaikie2015-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-4/+11
| | | | | | | | | | | | 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
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-301-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-4/+11
| | | | | | | | | Asserting when building compiler-rt when using a GCC host compiler. Reverting while I investigate. This reverts commit r224941. llvm-svn: 224970
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-171-4/+11
| | | | | | | | | Fails an ASan bootstrap - I'll try to reproduce locally & sort that out before recommitting. This reverts commit r224385. llvm-svn: 224441
* DebugInfo: Generalize debug info location handlingDavid Blaikie2014-12-161-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* DebugInfo: More accurate line information for placement new.David Blaikie2014-12-141-0/+3
| | | | | | | | | | | 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
* Implement the __builtin_call_with_static_chain GNU extension.Peter Collingbourne2014-12-121-3/+3
| | | | | | | | | | | | | | | | 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
* DebugInfo: Location information for scalar new expressionsDavid Blaikie2014-12-101-5/+7
| | | | llvm-svn: 223937
* DebugInfo: Correct location of aggregate assignmentDavid Blaikie2014-12-091-0/+2
| | | | llvm-svn: 223854
* Fix incorrect codegen for devirtualized calls to virtual overloaded operators.Nico Weber2014-12-031-42/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Wrap to 80 columns. No behavior change.Nico Weber2014-12-021-3/+4
| | | | llvm-svn: 223149
* [clang/asan] Do not emit memcpy for trivial operator= when ↵Kostya Serebryany2014-11-111-1/+1
| | | | | | | | | | | | | | | | | | -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
* CodeGen: Declutter the emitVirtualObjectDelete interfaceDavid Majnemer2014-11-011-7/+6
| | | | | | No functionality change intended. llvm-svn: 221043
* MS ABI: Properly call global delete when invoking virtual destructorsDavid Majnemer2014-10-311-36/+43
| | | | | | | | | | | | | | | | | | | | 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
* Fix bug 20116 - http://llvm.org/bugs/show_bug.cgi?id=20116Alexey Bataev2014-09-291-10/+9
| | | | | | | | Fixes incorrect codegen when devirtualization is aborted due to covariant return types. Differential Revision: http://reviews.llvm.org/D5321 llvm-svn: 218602
* Merge GetAddrOfCXXConstructor and GetAddrOfCXXDonstructor. NFC.Rafael Espindola2014-09-111-1/+2
| | | | llvm-svn: 217598
* Implement nonnull-attribute sanitizerAlexey Samsonov2014-09-081-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud