summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [PR41276] Fixed incorrect generation of addr space cast for 'this' in C++.Anastasia Stulova2019-04-041-5/+3
| | | | | | | | | | | | | | | Improved classification of address space cast when qualification conversion is performed - prevent adding addr space cast for non-pointer and non-reference types. Take address space correctly from the pointee. Also pass correct address space from 'this' object using AggValueSlot when generating addrspacecast in the constructor call. Differential Revision: https://reviews.llvm.org/D59988 llvm-svn: 357682
* IRGen: Remove StructorType; thread GlobalDecl through more code. NFCI.Peter Collingbourne2019-03-221-17/+14
| | | | | | | | This should make it easier to add more structor variants. Differential Revision: https://reviews.llvm.org/D59724 llvm-svn: 356822
* Fix MSVC constructor call extension after b92d290e48e9 (r353181).James Y Knight2019-02-061-31/+20
| | | | | | | | | | | | | | | | | | | | The assert added to EmitCall there was triggering in Windows Chromium builds, due to a mismatch of the return type. The MSVC constructor call extension (`this->Foo::Foo()`) was emitting the constructor call from 'EmitCXXMemberOrOperatorMemberCallExpr' via calling 'EmitCXXMemberOrOperatorCall', instead of 'EmitCXXConstructorCall'. On targets where HasThisReturn is true, that was failing to set the proper return type in the call info. Switching to calling EmitCXXConstructorCall also allowed removing some code e.g. the trivial copy/move support, which is already handled in EmitCXXConstructorCall. Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=928861 Differential Revision: https://reviews.llvm.org/D57794 llvm-svn: 353246
* [opaque pointer types] Fix the CallInfo passed to EmitCall in someJames Y Knight2019-02-051-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | edge cases. Currently, EmitCall emits a call instruction with a function type derived from the pointee-type of the callee. This *should* be the same as the type created from the CallInfo parameter, but in some cases an incorrect CallInfo was being passed. All of these fixes were discovered by the addition of the assert in EmitCall which verifies that the passed-in CallInfo matches the Callee's function type. As far as I know, these issues caused no bugs at the moment, as the correct types were ultimately being emitted. But, some would become problematic when pointee types are removed. List of fixes: * arrangeCXXConstructorCall was passing an incorrect value for the number of Required args, when calling an inheriting constructor where the inherited constructor is variadic. (The inheriting constructor doesn't actually get passed any of the user's args, but the code was calculating it as if it did). * arrangeFreeFunctionLikeCall was not including the count of the pass_object_size arguments in the count of required args. * OpenCL uses other address spaces for the "this" pointer. However, commonEmitCXXMemberOrOperatorCall was not annotating the address space on the "this" argument of the call. * Destructor calls were being created with EmitCXXMemberOrOperatorCall instead of EmitCXXDestructorCall in a few places. This was a problem because the calling convention sometimes has destructors returning "this" rather than void, and the latter function knows about that, and sets up the types properly (through calling arrangeCXXStructorDeclaration), while the former does not. * generateObjCGetterBody: the 'objc_getProperty' function returns type 'id', but was being called as if it returned the particular property's type. (That is of course the *dynamic* return type, and there's a downcast immediately after.) * OpenMP user-defined reduction functions (#pragma omp declare reduction) can be called with a subclass of the declared type. In such case, the call was being setup as if the function had been actually declared to take the subtype, rather than the base type. Differential Revision: https://reviews.llvm.org/D57664 llvm-svn: 353181
* [opaque pointer types] Trivial changes towards CallInst requiringJames Y Knight2019-02-031-2/+2
| | | | | | explicit function types. llvm-svn: 353009
* Remove redundant FunctionDecl argument from a couple functions.James Y Knight2019-02-021-3/+2
| | | | | | | | | | | | | | | | | | This argument was added in r254554 in order to support the pass_object_size attribute. However, in r296076, the attribute's presence is now also represented in FunctionProtoType's ExtParameterInfo, and thus it's unnecessary to pass along a separate FunctionDecl. The functions modified are: RequiredArgs::forPrototype{,Plus}, and CodeGenTypes::ConvertFunctionType. After this, it's also (again) unnecessary to have a separate ConvertFunctionType function ConvertType, so convert callers back to the latter, leaving the former as an internal helper function. llvm-svn: 352946
* Cleanup: replace uses of CallSite with CallBase.James Y Knight2019-01-301-11/+3
| | | | llvm-svn: 352595
* [ubsan] Check the correct size when sanitizing array new.Richard Smith2019-01-231-3/+9
| | | | | | We previously forgot to multiply the element size by the array bound. llvm-svn: 351924
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Fix cleanup registration for lambda captures.Richard Smith2019-01-171-18/+0
| | | | | | | | | | | | | | | | | Lambda captures should be destroyed if an exception is thrown only if the construction of the complete lambda-expression has not completed. (If the lambda-expression has been fully constructed, any exception will invoke its destructor, which will destroy the captures.) This is directly modeled after how we handle the equivalent situation in InitListExprs. Note that EmitLambdaLValue was unreachable because in C++11 onwards the frontend never creates the awkward situation where a prvalue expression (such as a lambda) is used in an lvalue context (such as the left-hand side of a class member access). llvm-svn: 351487
* In nothrow new-expressions, null-check the result if we're going toRichard Smith2019-01-101-2/+3
| | | | | | | | | apply sanitizers to it. This avoids a sanitizer false positive that we are initializing a null pointer. llvm-svn: 350779
* [AST] Store some data of CXXNewExpr as trailing objectsBruno Ricci2019-01-071-2/+2
| | | | | | | | | | | | | | | | | Store the optional array size expression, optional initialization expression and optional placement new arguments in a trailing array. Additionally store the range for the parenthesized type-id in a trailing object if needed since in the vast majority of cases the type is not parenthesized (not a single new expression in the translation unit of SemaDecl.cpp has a parenthesized type-id). This saves 2 pointers per CXXNewExpr in all cases, and 2 pointers + 8 bytes per CXXNewExpr in the common case where the type is not parenthesized. Differential Revision: https://reviews.llvm.org/D56134 Reviewed By: rjmccall llvm-svn: 350527
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* [NFC] Move storage of dispatch-version to GlobalDeclErich Keane2018-11-131-11/+13
| | | | | | | | | | | | | | | | | | | As suggested by Richard Smith, and initially put up for review here: https://reviews.llvm.org/D53341, this patch removes a hack that was used to ensure that proper target-feature lists were used when emitting cpu-dispatch (and eventually, target-clones) implementations. As a part of this, the GlobalDecl object is proliferated to a bunch more locations. Originally, this was put up for review (see above) to get acceptance on the approach, though discussion with Richard in San Diego showed he approved of the approach taken here. Thus, I believe this is acceptable for Review-After-commit Differential Revision: https://reviews.llvm.org/D53341 Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5 llvm-svn: 346757
* PR24164, PR39336: init-captures are not distinct full-expressions.Richard Smith2018-10-191-1/+0
| | | | | | | | | Rather, they are subexpressions of the enclosing lambda-expression, and any temporaries in them are destroyed at the end of that full-expression, or when the corresponding lambda-expression is destroyed if they are lifetime-extended. llvm-svn: 344801
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Remove trailing spaceFangrui Song2018-07-301-32/+32
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [UBSan] Strengthen pointer checks in 'new' expressionsSerge Pavlov2018-07-281-4/+16
| | | | | | | | | | | | | | | | | | | | With this change compiler generates alignment checks for wider range of types. Previously such checks were generated only for the record types with non-trivial default constructor. So the types like: struct alignas(32) S2 { int x; }; typedef __attribute__((ext_vector_type(2), aligned(32))) float float32x2_t; did not get checks when allocated by 'new' expression. This change also optimizes the checks generated for the arrays created in 'new' expressions. Previously the check was generated for each invocation of type constructor. Now the check is generated only once for entire array. Differential Revision: https://reviews.llvm.org/D49589 llvm-svn: 338199
* Rename invariant.group.barrier to launder.invariant.groupPiotr Padlewski2018-05-031-2/+2
| | | | | | | | | | | | | | Summary: This is one of the initial commit of "RFC: Devirtualization v2" proposal: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing Reviewers: rsmith, amharc, kuhar, sanjoy Subscribers: arsenm, nhaehnle, javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D45111 llvm-svn: 331448
* PR36992: do not store beyond the dsize of a class object unless we knowRichard Smith2018-04-051-8/+17
| | | | | | | | | | | | | | the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
* [Builtins] Overload __builtin_operator_new/delete to allow forwarding to ↵Eric Fiselier2018-03-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | usual allocation/deallocation functions. Summary: Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins. See llvm.org/PR22634 for more information about the libc++ bug. This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued. One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled. In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`. Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43047 llvm-svn: 328134
* Recommit r326946 after reducing CallArgList memory footprintYaxun Liu2018-03-151-4/+4
| | | | llvm-svn: 327634
* Revert r326946. It caused stack overflows by significantly increasing the ↵Richard Smith2018-03-101-4/+4
| | | | | | size of a CallArgList. llvm-svn: 327195
* CodeGen: Fix address space of indirect function argumentYaxun Liu2018-03-071-4/+4
| | | | | | | | | | | | | | | | | | | | | The indirect function argument is in alloca address space in LLVM IR. However, during Clang codegen for C++, the address space of indirect function argument should match its address space in the source code, i.e., default addr space, even for indirect argument. This is because destructor of the indirect argument may be called in the caller function, and address of the indirect argument may be taken, in either case the indirect function argument is expected to be in default addr space, not the alloca address space. Therefore, the indirect function argument should be mapped to the temp var casted to default address space. The caller will cast it to alloca addr space when passing it to the callee. In the callee, the argument is also casted to the default address space and used. CallArg is refactored to facilitate this fix. Differential Revision: https://reviews.llvm.org/D34367 llvm-svn: 326946
* IRGen: Move vtable load after argument evaluation.Peter Collingbourne2018-02-051-3/+1
| | | | | | | | | | | | | | This change reduces the live range of the loaded function pointer, resulting in a slight code size decrease (~10KB in clang), and also improves the security of CFI for virtual calls by making it less likely that the function pointer will be spilled, and ensuring that it is not spilled across a function call boundary. Fixes PR35353. Differential Revision: https://reviews.llvm.org/D42725 llvm-svn: 324286
* [CodeGen] Decorate aggregate accesses with TBAA tagsIvan A. Kosarev2018-01-251-13/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D41539 llvm-svn: 323421
* -fsanitize=vptr warnings on bad static types in dynamic_cast and typeidStephan Bergmann2017-12-281-5/+21
| | | | | | | | | | ...when such an operation is done on an object during con-/destruction. This is the cfe part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40295 llvm-svn: 321519
* [ubsan] Diagnose noreturn functions which returnVedant Kumar2017-12-211-2/+3
| | | | | | | | | | | | | | | | | | Diagnose 'unreachable' UB when a noreturn function returns. 1. Insert a check at the end of functions marked noreturn. 2. A decl may be marked noreturn in the caller TU, but not marked in the TU where it's defined. To diagnose this scenario, strip away the noreturn attribute on the callee and insert check after calls to it. Testing: check-clang, check-ubsan, check-ubsan-minimal, D40700 rdar://33660464 Differential Revision: https://reviews.llvm.org/D40698 llvm-svn: 321231
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-1/+1
| | | | llvm-svn: 321115
* IRGen: When performing CFI checks, load vtable pointer from vbase when ↵Peter Collingbourne2017-12-131-3/+5
| | | | | | | | | | | | | | necessary. Under the Microsoft ABI, it is possible for an object not to have a virtual table pointer of its own if all of its virtual functions were introduced by virtual bases. In that case, we need to load the vtable pointer from one of the virtual bases and perform the type check using its type. Differential Revision: https://reviews.llvm.org/D41036 llvm-svn: 320638
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-23/+72
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* Extract IRGen's constant-emitter into its own helper class and clean upJohn McCall2017-08-151-2/+3
| | | | | | | | | | | | the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* [Devirtualization] insert placement new barrier with -O0Piotr Padlewski2017-05-201-1/+2
| | | | | | | | | | | | | | | | Summary: To not break LTO with different optimizations levels, we should insert the barrier regardles of optimization level. Reviewers: rjmccall, rsmith, mehdi_amini Reviewed By: mehdi_amini Subscribers: mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D32401 llvm-svn: 303488
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-3/+3
| | | | | | | | | | | | | The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. This patch should not introduce any functional changes. Differential Revision: https://reviews.llvm.org/D33284 llvm-svn: 303358
* [ubsan] Reduce alignment checking of C++ object pointersVedant Kumar2017-04-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert an alignment check for the 'this' pointer at the start of each method/lambda. This allows clang to emit significantly fewer alignment checks overall, because if 'this' is aligned, so are its fields. This is essentially the same thing r295515 does, but for the alignment check instead of the null check. One difference is that we keep the alignment checks on member expressions where the base is a DeclRefExpr. There's an opportunity to diagnose unaligned accesses in this situation (as pointed out by Eli, see PR32630). Testing: check-clang, check-ubsan, and a stage2 ubsan build. Along with the patch from D30285, this roughly halves the amount of alignment checks we emit when compiling X86FastISel.cpp. Here are the numbers from patched/unpatched clangs based on r298160. ------------------------------------------ | Setup | # of alignment checks | ------------------------------------------ | unpatched, -O0 | 24326 | | patched, -O0 | 12717 | (-47.7%) ------------------------------------------ Differential Revision: https://reviews.llvm.org/D30283 llvm-svn: 300370
* Update Clang for LLVM rename AttributeSet -> AttributeListReid Kleckner2017-03-211-2/+2
| | | | llvm-svn: 298394
* [ubsan] Extend the nonnull arg check to ObjCVedant Kumar2017-03-061-1/+1
| | | | | | | | | | UBSan's nonnull argument check applies when a parameter has the "nonnull" attribute. The check currently works for FunctionDecls, but not for ObjCMethodDecls. This patch extends the check to work for ObjC. Differential Revision: https://reviews.llvm.org/D30599 llvm-svn: 296996
* [CodeGen] Fix ExtParameterInfo bugs in C++ CodeGen code.George Burgess IV2017-02-231-5/+16
| | | | | | | | | | | | | | | | This patch makes use of the prefix/suffix ABI argument distinction that was introduced in r295870, so that we now emit ExtParameterInfo at the correct offset for member calls that have added ABI arguments. I don't see a good way to test the generated param info, since we don't actually seem to use it in CGFunctionInfo outside of Swift. Any suggestions/thoughts for how to better test this are welcome. :) This patch also fixes a small bug with inheriting constructors: if we decide not to pass args into an base class ctor, we would still generate ExtParameterInfo as though we did. The added test-case is for that behavior. llvm-svn: 296024
* Rename a helper function, NFC.Vedant Kumar2017-02-231-1/+1
| | | | llvm-svn: 295918
* Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang, check-ubsan, and a stage2 ubsan build. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Changes since the initial commit: - Don't introduce any unintentional object-size or alignment checks. - Don't rely on IRGen of C labels in the test. Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295515
* Revert "Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)"Vedant Kumar2017-02-171-9/+4
| | | | | | | | This reverts commit r295401. It breaks the ubsan self-host. It inserts object size checks once per C++ method which fire when the structure is empty. llvm-svn: 295494
* Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Changes since the initial commit: don't rely on IRGen of C labels in the test. Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295401
* Revert "[ubsan] Reduce null checking of C++ object pointers (PR27581)"Vedant Kumar2017-02-171-9/+4
| | | | | | | | | | This reverts commit r295391. It breaks this bot: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/1898 I need to not rely on labels in the IR test. llvm-svn: 295396
* [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295391
* When the new expr's array size is an ICE, emit it as a constant expression.Nick Lewycky2017-02-131-1/+4
| | | | | | This bypasses integer sanitization checks which are redundant on the expression since it's been checked by Sema. Fixes a clang codegen assertion on "void test() { new int[0+1]{0}; }" when building with -fsanitize=signed-integer-overflow. llvm-svn: 295006
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-4/+1
| | | | | | | | | | | copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop. This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here. llvm-svn: 289618
* Insert a type check before reading vtable.Ivan Krasin2016-11-171-11/+22
| | | | | | | | | | | | | | | Summary: this is to prevent a situation when a pointer is invalid or null, but we get to reading from vtable before we can check that (possibly causing a segfault without a good diagnostics). Reviewers: pcc Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26559 llvm-svn: 287181
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-21/+82
| | | | | | | | | | | abstract information about the callee. NFC. The goal here is to make it easier to recognize indirect calls and trigger additional logic in certain cases. That logic will come in a later patch; in the meantime, I felt that this was a significant improvement to the code. llvm-svn: 285258
* [ubsan] Use the object pointer's type info for devirtualized callsVedant Kumar2016-10-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ubsan reports a false positive 'invalid member call' diagnostic on the following example (PR30478): struct Base1 { virtual int f1() { return 1; } }; struct Base2 { virtual int f1() { return 2; } }; struct Derived2 final : Base1, Base2 { int f1() override { return 3; } }; int t1() { Derived2 d; return static_cast<Base2 *>(&d)->f1(); } Adding the "final" attribute to a most-derived class allows clang to devirtualize member calls into an instance of that class. We should pass along the type info of the object pointer to avoid the FP. In this case, that means passing along the type info for 'Derived2' instead of 'Base2' when checking the dynamic type of static_cast<Base2 *>(&d2). Differential Revision: https://reviews.llvm.org/D25448 llvm-svn: 284636
OpenPOWER on IntegriCloud