summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGClass.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Justin Bogner2015-08-181-76/+43
| | | | | | | | | | | Bootstrap bots were failing: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/6382/ http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/2969 This reverts r245264. llvm-svn: 245267
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-08-181-43/+76
| | | | | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html Edit: Fixed version because of PR24479. http://reviews.llvm.org/D11859 llvm-svn: 245264
* Revert r245257 "Generating assumption loads of vptr after ctor call"Hans Wennborg2015-08-181-76/+43
| | | | | | It caused PR24479 llvm-svn: 245260
* Generating assumption loads of vptr after ctor callPiotr Padlewski2015-08-171-43/+76
| | | | | | | | | | | | Generating call assume(icmp %vtable, %global_vtable) after constructor call for devirtualization purposes. For more info go to: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D11859 llvm-svn: 245257
* Fix previous commit: poison only class members, simpler testsNaomi Musgrave2015-08-131-7/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Poisoning applied to only class members, and before dtors for base class invoked Implement poisoning of only class members in dtor, as opposed to also poisoning fields inherited from base classes. Members are poisoned only once, by the last dtor for a class. Skip poisoning if class has no fields. Verify emitted code for derived class with virtual destructor sanitizes its members only once. Removed patch file containing extraneous changes. Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D11951 Simplified test cases for use-after-dtor Summary: Simplified test cases to focus on one feature at time. Tests updated to align with new emission order for sanitizing callback. Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D12003 llvm-svn: 244933
* Revert "Implement poisoning of only class members in dtor, as opposed to ↵Naomi Musgrave2015-08-121-32/+7
| | | | | | | | | also poisoning fields inherited from base classes." This reverts commit 8dbbf3578a9a5d063232b59e558e5fe46e2cd42c. Rolled back due to buildbot failures on 'ninja check-clang'. llvm-svn: 244820
* Implement poisoning of only class members in dtor, as opposed to also ↵Naomi Musgrave2015-08-121-7/+32
| | | | | | | | | | | | | | | | | poisoning fields inherited from base classes. Verify emitted code for derived class with virtual destructor sanitizes its members only once. Changed emission order for dtor callback, so only the last dtor for a class emits the sanitizing callback, while ensuring that class members are poisoned before base class destructors are invoked. Skip poisoning of members, if class has no fields. Removed patch file containing extraneous changes. Summary: Poisoning applied to only class members, and before dtors for base class invoked Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D11951 llvm-svn: 244819
* Dtor callback emitted when msan attribute not repressed for this function.Naomi Musgrave2015-08-031-1/+2
| | | | | | | | | | | | | | | | | | Summary: In addition to checking compiler flags, the front-end also examines the attributes of the destructor definition to ensure that the SanitizeMemory attribute is attached. Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11727 refactored test into new file, revised how function attribute examined modified test to examine default dtor with and without attribute removed attribute check llvm-svn: 243912
* Updated test regex and flagsNaomi Musgrave2015-07-301-2/+2
| | | | llvm-svn: 243669
* repress tail call optimization when performing use-after-dtor sanitizationNaomi Musgrave2015-07-301-0/+4
| | | | | | | | | | Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11613 llvm-svn: 243668
* Pass an iterator range to EmitCallArgsDavid Blaikie2015-07-211-2/+2
| | | | llvm-svn: 242824
* [AST] Cleanup ExprIterator.Benjamin Kramer2015-07-181-1/+1
| | | | | | | | - 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
* CodeGen: Improve CFI type blacklisting mechanism.Peter Collingbourne2015-07-151-9/+0
| | | | | | | | | | We now use the sanitizer special case list to decide which types to blacklist. We also support a special blacklist entry for types with a uuid attribute, which are generally COM types whose virtual tables are defined externally. Differential Revision: http://reviews.llvm.org/D11096 llvm-svn: 242286
* Fix for clang memcpyizer bugs 23911 and 23924 (patch by Denis Zobnin)Alexey Bataev2015-07-141-13/+23
| | | | | | | The fix is to remove duplicate copy-initialization of the only memcpy-able struct member and to correct the address of aggregately initialized members in destructors' calls during stack unwinding (in order to obtain address of struct member by using GEP instead of 'bitcast'). Differential Revision: http://reviews.llvm.org/D10990 llvm-svn: 242127
* Basic code generation for MSan use-after-dtor.Evgeniy Stepanov2015-07-141-0/+23
| | | | | | | | | Under the -fsanitize-memory-use-after-dtor (disabled by default) insert an MSan runtime library call at the end of every destructor. Patch by Naomi Musgrave. llvm-svn: 242097
* Update commentUlrich Weigand2015-07-131-5/+1
| | | | | | | As noticed by David Majnemer, update an out-of-date comment in CGClass.cpp after the r241916 commit. llvm-svn: 242021
* Respect alignment of nested bitfieldsUlrich Weigand2015-07-101-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test: struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YBitfield { char x; struct XBitfield y; } __attribute((packed)); struct YBitfield gbitfield; unsigned test7() { // CHECK: @test7 // CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4 return gbitfield.y.b2; } The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single i32 is of course possible, but that still doesn't make it 4-byte aligned as it remains packed at offset 1 in the surrounding gbitfield object. This alignment was changed by commit r169489, which also introduced changes to bitfield access code in CGExpr.cpp. Code before that change used to take into account *both* the alignment of the field to be accessed within the current struct, *and* the alignment of that outer struct itself; this logic was removed by the above commit. Neglecting to consider both values can cause incorrect code to be generated (I've seen an unaligned access crash on SystemZ due to this bug). In order to always use the best known alignment value, this patch removes the CGBitFieldInfo::StorageAlignment member and replaces it with a StorageOffset member specifying the offset from the start of the surrounding struct to the bitfield's underlying storage. This offset can then be combined with the best-known alignment for a bitfield access lvalue to determine the alignment to use when accessing the bitfield's storage. Differential Revision: http://reviews.llvm.org/D11034 llvm-svn: 241916
* CFI: Emit correct bit set information if RTTI is disabled under MS ABI.Peter Collingbourne2015-07-091-2/+1
| | | | | | | | | | | | | | We were previously creating bit set entries at virtual table offset sizeof(void*) unconditionally under the Microsoft C++ ABI. This is incorrect if RTTI data is disabled; in that case the "address point" is at offset 0. This change modifies bit set emission to take into account whether RTTI data is being emitted. Also make a start on a blacklisting scheme for records. Differential Revision: http://reviews.llvm.org/D11048 llvm-svn: 241845
* [EH] Fix for clang bug 24005 - no cleanup for array of memcpy-able objects ↵Alexey Bataev2015-07-081-0/+5
| | | | | | | | | in struct (patch by Denis Zobnin) The fix is to emit cleanup for arrays of memcpy-able objects in struct if an exception is thrown later during copy-construction. Differential Revision: http://reviews.llvm.org/D10989 llvm-svn: 241670
* [Sema] Commit a better fix for r240242Davide Italiano2015-06-261-4/+5
| | | | | | | | | | | Skip calls to HasTrivialDestructorBody() in the case where the destructor is never invoked. Alternatively, Richard proposed to change Sema to declare a trivial destructor for anonymous union member, which seems too wasteful. Differential Revision: http://reviews.llvm.org/D10508 llvm-svn: 240742
* [MS ABI] Rework member pointer conversionDavid Majnemer2015-06-231-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member pointers in the MS ABI are made complicated due to the following: - Virtual methods in the most derived class (MDC) might live in a vftable in a virtual base. - There are four different representations of member pointer: single inheritance, multiple inheritance, virtual inheritance and the "most general" representation. - Bases might have a *more* general representation than classes which derived from them, a most surprising result. We believed that we could treat all member pointers as-if they were a degenerate case of the multiple inheritance model. This fell apart once we realized that implementing standard member pointers using this ABI requires referencing members with a non-zero vbindex. On a bright note, all but the virtual inheritance model operate rather similarly. The virtual inheritance member pointer representation awkwardly requires a virtual base adjustment in order to refer to entities in the MDC. However, the first virtual base might be quite far from the start of the virtual base. This means that we must add a negative non-virtual displacement. However, things get even more complicated. The most general representation interprets vbindex zero differently from the virtual inheritance model: it doesn't reference the vbtable at all. It turns out that this complexity can increase for quite some time: consider a derived to base conversion from the most general model to the multiple inheritance model... To manage this complexity we introduce a concept of "normalized" member pointer which allows us to treat all three models as the most general model. Then we try to figure out how to map this generalized member pointer onto the destination member pointer model. I've done my best to furnish the code with comments explaining why each adjustment is performed. This fixes PR23878. llvm-svn: 240384
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-6/+6
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-6/+6
| | | | | | | | | | | | 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
* [Codegen] Don't crash if destructor is not accessible.Davide Italiano2015-06-211-0/+4
| | | | | | | | | | | Testcase provided, in the PR, by Christian Shelton and reduced by David Majnemer. PR: 23584 Differential Revision: http://reviews.llvm.org/D10508 Reviewed by: rnk llvm-svn: 240242
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-17/+39
| | | | | | | | | | | | | | | | | 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
* add ConstEvaluatedExprVisitorScott Douglass2015-06-101-5/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D10210 llvm-svn: 239474
* InstrProf: Increment the profile counter for all types of destructorJustin Bogner2015-05-201-4/+4
| | | | | | | | | | | | -fprofile-instr-generate does not emit counter increment intrinsics for Dtor_Deleting and Dtor_Complete destructors with assigned counters. This causes unnecessary [-Wprofile-instr-out-of-date] warnings during profile-use runs even if the source has never been modified since profile collection. Patch by Betul Buyukkurt. Thanks! llvm-svn: 237804
* CodeGen: Remove some trailing whitespace. NFCJustin Bogner2015-05-201-96/+96
| | | | llvm-svn: 237802
* API update for streamlining of IRBuilder::CreateCall to just use ↵David Blaikie2015-05-181-6/+6
| | | | | | ArrayRef/initializer_list+braced init llvm-svn: 237625
* PR23373: A defaulted union copy constructor that is not trivial must still beRichard Smith2015-04-291-25/+37
| | | | | | emitted as a memcpy. llvm-svn: 236142
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-4/+2
| | | | | | | | | The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
* Implement CFI type checks for non-virtual calls.Peter Collingbourne2015-04-021-8/+9
| | | | | | | | | | | | 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
* Implement bad cast checks using control flow integrity information.Peter Collingbourne2015-03-141-1/+90
| | | | | | | | | | | This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+1
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* Implement Control Flow Integrity for virtual calls.Peter Collingbourne2015-02-201-0/+33
| | | | | | | | | | | | | | | This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
* CodeGen: Copy-ctorm must obey the destination's alignment requirementDavid Majnemer2015-02-031-3/+6
| | | | | | | | We would synthesize memcpy intrinsics when emitting calls to trivial C++ constructors but we wouldn't take into account the alignment of the destination. llvm-svn: 228061
* The prefix 'Ms-' should be 'MS-'David Majnemer2015-02-021-1/+1
| | | | | | | Clang is otherwise consistent that Microsoft be abbreviated as MS, not Ms. llvm-svn: 227842
* MS ABI: Implement support for 'novtable'David Majnemer2015-02-021-0/+8
| | | | | | | | | | It is common for COM interface classes to be marked as 'novtable' to tell the compiler that constructors and destructors should not reference virtual function tables. This commit implements this feature in clang. llvm-svn: 227796
* DebugInfo: Correct the debug location of non-static data member initializersDavid Blaikie2015-01-181-2/+1
| | | | | | | | | | This was causing some trouble for otherwise dead code removed in r225085 (reverted in r225361). The location being set for function arguments was leaking out to the call which wasn't setting its own location (so a quality bug turned into a crasher with r225085). Fix this so r225085 can be recommitted. llvm-svn: 226382
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8/+10
| | | | | | | | | | | | 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-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8/+10
| | | | | | | | | 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-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-8/+10
| | | | | | | | | 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-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Emit the correct location for initialization of a complex variableDavid Blaikie2014-12-091-1/+1
| | | | | | Especially useful for sanitizer reports. llvm-svn: 223825
* DebugInfo: Correctly identify the location of C++ member initializer list ↵David Blaikie2014-12-091-5/+7
| | | | | | | | | | | | | elements This particularly helps the fidelity of ASan reports (which can occur even in these examples - if, for example, one uses placement new over a buffer of insufficient size - now ASan will correctly identify which member's initialization went over the end of the buffer). This doesn't cover all types of members - more coming. llvm-svn: 223726
* No memcpy for copy ctor with -fsanitize-address-field-padding=1Kostya Serebryany2014-12-061-2/+3
| | | | | | | | | | | | | | | | | | | Summary: When -fsanitize-address-field-padding=1 is present don't emit memcpy for copy constructor. Thanks Nico for the extra test case. Test Plan: regression tests Reviewers: thakis, rsmith Reviewed By: rsmith Subscribers: rsmith, cfe-commits Differential Revision: http://reviews.llvm.org/D6515 llvm-svn: 223563
* Cast vtable address points to i32 (...)** to enable more globaloptReid Kleckner2014-12-031-4/+8
| | | | | | | | | | | | We currently use i32 (...)** as the type of the vptr field in the LLVM struct type. LLVM's GlobalOpt prefers any bitcasts to be on the side of the data being stored rather than on the pointer being stored to. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D5916 llvm-svn: 223267
OpenPOWER on IntegriCloud