summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGClass.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Fix incorrect codegen for devirtualized calls to virtual overloaded operators.Nico Weber2014-12-031-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-1/+1
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* [Sanitizer] Refactor sanitizer options in LangOptions.Alexey Samsonov2014-11-111-2/+2
| | | | | | | | | | | | | | | | | | Get rid of ugly SanitizerOptions class thrust into LangOptions: * Make SanitizeAddressFieldPadding a regular language option, and rely on default behavior to initialize/reset it. * Make SanitizerBlacklistFile a regular member LangOptions. * Introduce the helper class "SanitizerSet" to represent the set of enabled sanitizers and make it a member of LangOptions. It is exactly the entity we want to cache and modify in CodeGenFunction, for instance. We'd also be able to reuse SanitizerSet in CodeGenOptions for storing the set of recoverable sanitizers, and in the Driver to represent the set of sanitizers turned on/off by the commandline flags. No functionality change. llvm-svn: 221653
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-2/+2
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* Get rid of SanitizerOptions::Disabled global. NFC.Alexey Samsonov2014-10-301-6/+4
| | | | | | | | | SanitizerOptions is not even a POD now, so having global variable of this type, is not nice. Instead, provide a regular constructor and clear() method, and let each CodeGenFunction has its own copy of SanitizerOptions it uses. llvm-svn: 220920
* fix -fsanitize-address-field-padding for the cases with virtual base classesKostya Serebryany2014-10-171-3/+1
| | | | | | | | | | | | | | | | Summary: Correctly compute the non-virtual size of a class. Test Plan: Build SPEC 2016 with -fsanitize-address-field-padding Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5848 llvm-svn: 220089
* Insert poisoned paddings between fields in C++ classes so that ↵Kostya Serebryany2014-10-161-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | AddressSanitizer can find intra-object-overflow bugs Summary: The general approach is to add extra paddings after every field in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings (CodeGen/CGClass.cpp). Everything is done under the flag -fsanitize-address-field-padding. The blacklist file (-fsanitize-blacklist) allows to avoid the transformation for given classes or source files. See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding Reviewers: samsonov, rnk, rsmith Reviewed By: rsmith Subscribers: majnemer, cfe-commits Differential Revision: http://reviews.llvm.org/D5687 llvm-svn: 219961
* MS ABI: Use the correct this arg when generating implicit array copy ctorDavid Majnemer2014-10-151-3/+2
| | | | | | | We assumed the last argument of the copy constructor was the this pointer. However, this is not the case under the MS ABI. llvm-svn: 219775
* Sanitize upcasts and conversion to virtual base.Alexey Samsonov2014-10-131-6/+17
| | | | | | | | | | | This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
* CodeGen: FieldMemcpyizer didn't handle copies starting inside bitfieldsDavid Majnemer2014-10-101-4/+16
| | | | | | | | | | | | | It's possible to construct cases where the first field we are trying to copy is in the middle of an IR field. In some complicated cases, we would fail to use an appropriate offset inside the object. Earlier builds of clang seemed to miscompile the code by copying an insufficient number of bytes. Up until now, we would assert: the copying offset was insufficiently aligned. This fixes PR21232. llvm-svn: 219524
* Add support for putting constructors and destructos in explicit comdats.Rafael Espindola2014-09-161-0/+3
| | | | | | | | | | | | | | | | | | There are situations when clang knows that the C1 and C2 constructors or the D1 and D2 destructors are identical. We already optimize some of these cases, but cannot optimize it when the GlobalValue is weak_odr. The problem with weak_odr is that an old TU seeing the same code will have a C1 and a C2 comdat with the corresponding symbols. We cannot suddenly start putting the C2 symbol in the C1 comdat as we cannot guarantee that the linker will not pick a .o with only C1 in it. The solution implemented by GCC is to expand the ABI to have a comdat whose name uses a C5/D5 suffix and always has both symbols. That is what this patch implements. llvm-svn: 217874
* MS ABI: Use the correct this arg when generating implict copy ctorDavid Majnemer2014-09-111-4/+5
| | | | | | | | | | We assumed that the incoming this argument would be the last argument. However, this is not true under the MS ABI. This fixes PR20897. llvm-svn: 217642
* Merge GetAddrOfCXXConstructor and GetAddrOfCXXDonstructor. NFC.Rafael Espindola2014-09-111-3/+4
| | | | llvm-svn: 217598
* Implement nonnull-attribute sanitizerAlexey Samsonov2014-09-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Handle constructors and destructors a bit more uniformly in CodeGen.Rafael Espindola2014-09-081-1/+2
| | | | | | | | | 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
* Kill one of EmitCallArgs overloads. NFC.Alexey Samsonov2014-08-281-2/+1
| | | | llvm-svn: 216635
OpenPOWER on IntegriCloud