summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGClass.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [CodeGen] Note where we add ABI-specific args in ctors. NFC.George Burgess IV2017-02-221-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Meta: The ultimate goal is to teach ExtParameterInfo about pass_object_size attributes. This is necessary for that, since our ExtParameterInfo is a bit buggy in C++. I plan to actually make use of this Prefix/Suffix info in the near future, but I like small single-purpose changes. Especially when those changes are hard to actually test... At the moment, some of our C++-specific CodeGen pretends that ABIs can only add arguments to the beginning of a function call. This isn't quite correct: args can be appended to the end, as well. It hasn't mattered much until now, since we seem to only use this "number of arguments added" data when calculating the ExtParameterInfo to use when making a CGFunctionInfo. Said ExtParameterInfo is currently only used for ParameterABIs (Swift) and ns_consumed (ObjC). So, this patch allows ABIs to indicate whether args they added were at the beginning or end of an argument list. We can use this information to emit ExtParameterInfos more correctly, though like said, that bit is coming soon. No tests since this is theoretically a nop. llvm-svn: 295870
* [ubsan] Pass a set of checks to skip to EmitTypeCheck() (NFC)Vedant Kumar2017-02-171-2/+6
| | | | | | | | | | | CodeGenFunction::EmitTypeCheck accepts a bool flag which controls whether or not null checks are emitted. Make this a bit more flexible by changing the bool to a SanitizerSet. Needed for an upcoming change which deals with a scenario in which we only want to emit null checks. llvm-svn: 295514
* Prevent ICE in dllexport class with _Atomic data memberWarren Ristow2017-02-021-4/+5
| | | | | | | | | | Guard against a null pointer dereference that caused Clang to crash when processing a class containing an _Atomic qualified data member, and that is tagged with 'dllexport'. Differential Revision: https://reviews.llvm.org/D29208 llvm-svn: 293911
* CodeGen: add a LLVM_FALLTHROUGH to a fallthrough (NFC)Saleem Abdulrasool2017-02-021-3/+3
| | | | | | Drive by cleanup noticed while investigating an IR verifier assertion. llvm-svn: 293867
* clang-cl: Evaluate arguments left-to-right in constructor call with ↵Hans Wennborg2017-02-011-1/+5
| | | | | | | | | | | | initializer list (PR31831) clang-cl would evaluate the arguments right-to-left (see PR), and for non-Windows targets I suppose we only got it because we were already emitting left-to-right in CodeGenFunction::EmitCallArgs. Differential Revision: https://reviews.llvm.org/D29350 llvm-svn: 293732
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-163/+9
| | | | | | | | | | | 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
* [clang] Version support for UBSan handlersFilipe Cabecinhas2016-12-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | This adds a way for us to version any UBSan handler by itself. The patch overrides D21289 for a better implementation (we're able to rev up a single handler). After this, then we can land a slight modification of D19667+D19668. We probably don't want to keep all the versions in compiler-rt (maybe we want to deprecate on one release and remove the old handler on the next one?), but with this patch we will loudly fail to compile when mixing incompatible handler calls, instead of silently compiling and then providing bad error messages. Reviewers: kcc, samsonov, rsmith, vsk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21695 llvm-svn: 289444
* PR30937: don't devirtualize if we find that the callee is a pure virtualRichard Smith2016-11-111-23/+20
| | | | | | | | function. In that case, there is no requirement that the callee is actually defined, and the code may in fact be valid and have defined behavior if the virtual call is unreachable. llvm-svn: 286534
* Improve obvious-most-derived-type devirtualization:Richard Smith2016-11-031-37/+15
| | | | | | | | | | | | | | * if the base is produced by a series of derived-to-base conversions, check the expression inside them when looking for an expression with a known dynamic type * step past MaterializeTemporaryExprs when checking for a known dynamic type * when checking for a known dynamic type, treat all class prvalues as having a known dynamic type after skipping all relevant rvalue subobject adjustments * treat callees formed by pointer-to-member access for a non-reference member type like callees formed by member access. llvm-svn: 285954
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-6/+8
| | | | | | | | | | | 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
* [CodeGen] Devirtualize calls to methods marked final in a derived classVedant Kumar2016-10-201-7/+15
| | | | | | | | | | If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
* When copying an array into a lambda, destroy temporaries fromJohn McCall2016-07-201-0/+35
| | | | | | | | | the copy-constructor immediately and enter a partial array cleanup for previously-copied elements. Fixes PR28595. llvm-svn: 276180
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-46/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* CodeGen: Start emitting checked loads when both trapping CFI and ↵Peter Collingbourne2016-06-251-0/+36
| | | | | | | | -fwhole-program-vtables are enabled. Differential Revision: http://reviews.llvm.org/D21122 llvm-svn: 273757
* CodeGen: Update Clang to use the new type metadata.Peter Collingbourne2016-06-241-20/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
* Use more ArrayRefsDavid Majnemer2016-06-241-2/+2
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273647
* Implementation of VlA of GNU C++ extension, by Vladimir Yakovlev.Alexey Bataev2016-04-291-1/+1
| | | | | | | This enables GNU C++ extension "Variable length array" by default. Differential Revision: http://reviews.llvm.org/D18823 llvm-svn: 268018
* Re-apply r267784, r267824 and r267830.Peter Collingbourne2016-04-281-2/+7
| | | | | | I have updated the compiler-rt tests. llvm-svn: 267903
* Revert r267784, r267824 and r267830.Benjamin Kramer2016-04-281-7/+2
| | | | | | | | | | It makes compiler-rt tests fail if the gold plugin is enabled. Revert "Rework interface for bitset-using features to use a notion of LTO visibility." Revert "Driver: only produce CFI -fvisibility= error when compiling." Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi." llvm-svn: 267871
* Rework interface for bitset-using features to use a notion of LTO visibility.Peter Collingbourne2016-04-271-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Bitsets, and the compiler features they rely on (vtable opt, CFI), only have visibility within the LTO'd part of the linkage unit. Therefore, only enable these features for classes with hidden LTO visibility. This notion is based on object file visibility or (on Windows) dllimport/dllexport attributes. We provide the [[clang::lto_visibility_public]] attribute to override the compiler's LTO visibility inference in cases where the class is defined in the non-LTO'd part of the linkage unit, or where the ABI supports calling classes derived from abstract base classes with hidden visibility in other linkage units (e.g. COM on Windows). If the cross-DSO CFI mode is enabled, bitset checks are emitted even for classes with public LTO visibility, as that mode uses a separate mechanism to cause bitsets to be exported. This mechanism replaces the whole-program-vtables blacklist, so remove the -fwhole-program-vtables-blacklist flag. Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the support for the special attr:uuid blacklist entry is removed. Differential Revision: http://reviews.llvm.org/D18635 llvm-svn: 267784
* [modules] Remove CXX_CTOR_INITIALIZERS_OFFSETS table. Instead of storing an IDRichard Smith2016-04-131-1/+1
| | | | | | | | of a table entry in the corresponding decl, store an offset from the current record to the relevant CXX_CTOR_INITIALIZERS record. This results in fewer indirections and a minor .pcm file size reduction. llvm-svn: 266254
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
* 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
* Add whole-program vtable optimization feature to Clang.Peter Collingbourne2016-02-241-5/+25
| | | | | | | | | 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
* Fix some Clang-tidy readability-redundant-control-flow warnings; other minor ↵Eugene Zelenko2016-02-101-13/+9
| | | | | | | | fixes. Differential revision: http://reviews.llvm.org/D17060 llvm-svn: 260414
* [PGO] Fix issue: explicitly defaulted assignop is not profiledXinliang David Li2016-02-091-0/+1
| | | | | | | Differential Revision: http://reviews.llvm.org/D16947 llvm-svn: 260270
* [cfi] Safe handling of unaddressable vtable pointers (clang).Evgeniy Stepanov2016-02-031-3/+15
| | | | | | | | | | | Avoid crashing when printing diagnostics for vtable-related CFI errors. In diagnostic mode, the frontend does an additional check of the vtable pointer against the set of all known vtable addresses and lets the runtime handler know if it is safe to inspect the vtable. http://reviews.llvm.org/D16823 llvm-svn: 259716
* Use a consistent spelling for vtables.Eric Christopher2016-01-291-1/+1
| | | | llvm-svn: 259137
* [cfi] Cross-DSO CFI diagnostic mode (clang part)Evgeniy Stepanov2016-01-251-10/+13
| | | | | | | | | | | | | | * Runtime diagnostic data for cfi-icall changed to match the rest of cfi checks * Layout of all CFI diagnostic data changed to put Kind at the beginning. There is no ABI stability promise yet. * Call cfi_slowpath_diag instead of cfi_slowpath when needed. * Emit __cfi_check_fail function, which dispatches a CFI check faliure according to trap/recover settings of the current module. * A tiny driver change to match the way the new handlers are done in compiler-rt. llvm-svn: 258745
* Introduce -fsanitize-stats flag.Peter Collingbourne2016-01-161-0/+17
| | | | | | | | | This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
* Cross-DSO control flow integrity (Clang part).Evgeniy Stepanov2015-12-151-6/+13
| | | | | | | | | | | | | | Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
* Fix Clang-tidy modernize-use-nullptr warnings in source directories; other ↵Hans Wennborg2015-10-061-10/+8
| | | | | | | | | | minor cleanups Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13406 llvm-svn: 249484
* Emiting invariant.group.barrier for ctors bugfixPiotr Padlewski2015-10-021-10/+11
| | | | | | | | | | | | | Ensure that the vptr store in the most-derived constructor is not behind an invariant group barrier. Previously, the base-most vptr store would be the one behind no barrier, and that could result in the creator of the object thinking it had the base-most vtable. This bug caused clang call pure virtual functions when called from constructor body. http://reviews.llvm.org/D13373 llvm-svn: 249197
* Generate assume loads only with -fstrict-vtable-pointersPiotr Padlewski2015-09-281-1/+4
| | | | | | | Temporary fix till InstCombine and other possible passes will be efficient to handle multiple assumes. llvm-svn: 248734
* CGClass.cpp: Fix a warning in -Asserts. [-Wunused-private-field]NAKAMURA Takumi2015-09-161-0/+1
| | | | llvm-svn: 247778
* Implementation and testing for poisoning vtableNaomi Musgrave2015-09-161-17/+55
| | | | | | | | | | | | | | | | | | | | | | ptr in dtor. Summary: After destruction, invocation of virtual functions prevented by poisoning vtable pointer. Reviewers: eugenis, kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12712 Fixed testing callback emission order to account for vptr. Poison vtable in either complete or base dtor, depending on if virtual bases exist. If virtual bases exist, poison in complete dtor. Otherwise, poison in base. Remove commented-out block. llvm-svn: 247762
* Decorating vptr load & stores with !invariant.groupPiotr Padlewski2015-09-151-6/+18
| | | | | | | | | | 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-3/+30
| | | | | | | | | For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12312 llvm-svn: 247723
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-09-151-47/+86
| | | | | | | | | | | | | | | | | | 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 and other bug caused in chrome. After this patch got reverted because of ScalarEvolution bug (D12719) Merged after John McCall big patch (Added Address). http://reviews.llvm.org/D11859 http://reviews.llvm.org/D12865 llvm-svn: 247646
* Revert "Always_inline codegen rewrite" and 2 follow-ups.Evgeniy Stepanov2015-09-141-1/+1
| | | | | | | | | | Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
* Always_inline codegen rewrite.Evgeniy Stepanov2015-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247494
* Revert "Specify target triple in alwaysinline tests."Evgeniy Stepanov2015-09-111-1/+1
| | | | | | | | | Revert "Always_inline codegen rewrite." Breaks gdb & lldb tests. Breaks on Fedora 22 x86_64. llvm-svn: 247491
* Always_inline codegen rewrite.Evgeniy Stepanov2015-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247465
* Revert "Generating assumption loads of vptr after ctor call (fixed)"Piotr Padlewski2015-09-101-87/+47
| | | | | | | | It seems that there is small bug, and we can't generate assume loads when some virtual functions have internal visibiliy This reverts commit 982bb7d966947812d216489b3c519c9825cacbf2. llvm-svn: 247332
* CFI: Introduce -fsanitize=cfi-icall flag.Peter Collingbourne2015-09-101-5/+2
| | | | | | | | | | This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
* Generating assumption loads of vptr after ctor call (fixed)Piotr Padlewski2015-09-091-47/+87
| | | | | | | | | | | | | | | | | 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. After this patch got reverted because of ScalarEvolution bug (D12719) Merged after John McCall big patch (Added Address). http://reviews.llvm.org/D11859 llvm-svn: 247199
* clangCodeGen: Fix comments. [-Wdocumentation]NAKAMURA Takumi2015-09-081-1/+1
| | | | llvm-svn: 246995
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-120/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a couple of \param(s) in r246815. [-Wdocumentation]NAKAMURA Takumi2015-09-041-2/+2
| | | | llvm-svn: 246838
* Refactored dtor sanitizing into EHScopeStackNaomi Musgrave2015-09-031-59/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Dtor sanitization handled amidst other dtor cleanups, between cleaning bases and fields. Sanitizer call pushed onto stack of cleanup operations. Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D12022 Refactoring dtor sanitizing emission order. - Support multiple inheritance by poisoning after member destructors are invoked, and before base class destructors are invoked. - Poison for virtual destructor and virtual bases. - Repress dtor aliasing when sanitizing in dtor. - CFE test for dtor aliasing, and repression of aliasing in dtor code generation. - Poison members on field-by-field basis, with collective poisoning of trivial members when possible. - Check msan flags and existence of fields, before dtor sanitizing, and when determining if aliasing is allowed. - Testing sanitizing bit fields. llvm-svn: 246815
OpenPOWER on IntegriCloud