summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ubsan] Don't emit function signatures for non-static member functionsVedant Kumar2017-10-141-2/+10
| | | | | | | | | | | | | | | | | | The function sanitizer only checks indirect calls through function pointers. This excludes all non-static member functions (constructor calls, calls through thunks, etc. all use a separate code path). Don't emit function signatures for functions that won't be checked. Apart from cutting down on code size, this should fix a regression on Linux caused by r313096. For context, see the mailing list discussion: r313096 - [ubsan] Function Sanitizer: Don't require writable text segments Testing: check-clang, check-ubsan Differential Revision: https://reviews.llvm.org/D38913 llvm-svn: 315786
* Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along ↵Ivan A. Kosarev2017-10-131-3/+3
| | | | | | | | | | with LValue base info", r315731. With this change we fail on the clang-x86_64-linux-selfhost-modules builder. Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315739
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-3/+3
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315731
* [CodeGen] getNaturalTypeAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-6/+13
| | | | | | | | | | base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38794 llvm-svn: 315708
* [CodeGen] Generate TBAA info along with LValue base infoIvan A. Kosarev2017-10-121-1/+2
| | | | | | | | | | | | | | | | | | This patch enables explicit generation of TBAA information in all cases where LValue base info is propagated or constructed in non-trivial ways. Eventually, we will consider each of these cases to make sure the TBAA information is correct and not too conservative. For now, we just fall back to generating TBAA info from the access type. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38733 llvm-svn: 315575
* Refine generation of TBAA information in clangIvan A. Kosarev2017-10-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is an attempt to clarify and simplify generation and propagation of TBAA information. The idea is to pack all values that describe a memory access, namely, base type, access type and offset, into a single structure. This is supposed to make further changes, such as adding support for unions and array members, easier to prepare and review. DecorateInstructionWithTBAA() is no more responsible for converting types to tags. These implicit conversions not only complicate reading the code, but also suggest assigning scalar access tags while we generally prefer full-size struct-path tags. TBAAPathTag is replaced with TBAAAccessInfo; the latter is now the type of the keys of the cache map that translates access descriptors to metadata nodes. Fixed a bug with writing to a wrong map in getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()). We now check for valid base access types every time we dereference a field. The original code only checks the top-level base type. See isValidBaseType() / isTBAAPathStruct() calls. Some entities have been renamed to sound more adequate and less confusing/misleading in presence of path-aware TBAA information. Now we do not lookup twice for the same cache entry in getAccessTagInfo(). Refined relevant comments and descriptions. Differential Revision: https://reviews.llvm.org/D37826 llvm-svn: 315048
* Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"Ivan A. Kosarev2017-10-051-1/+1
| | | | | | | | D37826 has been mistakenly committed where it should be the patch from D38503. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314978
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314977
* [CodeGen] Do not refer to complete TBAA info where we actually deal with ↵Ivan A. Kosarev2017-10-021-1/+1
| | | | | | | | | | | | | | just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 llvm-svn: 314657
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* [ubsan] Function Sanitizer: Don't require writable text segmentsVedant Kumar2017-09-131-1/+41
| | | | | | | | | | | | | | | | | | This change will make it possible to use -fsanitize=function on Darwin and possibly on other platforms. It fixes an issue with the way RTTI is stored into function prologue data. On Darwin, addresses stored in prologue data can't require run-time fixups and must be PC-relative. Run-time fixups are undesirable because they necessitate writable text segments, which can lead to security issues. And absolute addresses are undesirable because they break PIE mode. The fix is to create a private global which points to the RTTI, and then to encode a PC-relative reference to the global into prologue data. Differential Revision: https://reviews.llvm.org/D37597 llvm-svn: 313096
* Expose -mllvm -accurate-sample-profile to clang.Dehao Chen2017-08-241-0/+4
| | | | | | | | | | | | | | Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20% Reviewers: davidxl, rsmith Reviewed By: davidxl, rsmith Subscribers: mehdi_amini, eraman, sanjoy, cfe-commits Differential Revision: https://reviews.llvm.org/D37091 llvm-svn: 311707
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-241-2/+14
| | | | | | | | | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). Do not sanitize the 'this' pointer of a member call operator for a lambda with no capture-default, since that call operator can legitimately be called with a null this pointer from the static invoker function. Any actual call with a null this pointer should still be caught in the caller (if it is being sanitized). This reinstates r311589 (reverted in r311680) with the above fix. llvm-svn: 311695
* Revert "[ubsan] PR34266: When sanitizing the 'this' value for a member ↵Adrian Prantl2017-08-241-2/+2
| | | | | | | | | function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any)." This reverts commit r311589 because of bot breakage. http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4115/consoleFull#15752874848254eaf0-7326-4999-85b0-388101f2d404. llvm-svn: 311680
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-231-2/+2
| | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). llvm-svn: 311589
* Clean up some lambda conversion operator code, NFCReid Kleckner2017-08-041-8/+3
| | | | | | | | | | | | | | We don't need special handling in CodeGenFunction::GenerateCode for lambda block pointer conversion operators anymore. The conversion operator emission code immediately calls back to the generic EmitFunctionBody. Rename EmitLambdaStaticInvokeFunction to EmitLambdaStaticInvokeBody for better consistency with the other Emit*Body methods. I'm preparing to do something about PR28299, which touches this code. llvm-svn: 310145
* Reland "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-0/+28
| | | | | | | | Reland r310097 with a fix for a debug assertion in NamedDecl.getName() Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310132
* Revert "Reland "CFI: blacklist STL allocate() from unrelated-casts""Vlad Tsyrklevich2017-08-041-27/+0
| | | | | | This reverts commit r310105. llvm-svn: 310121
* Reland "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-0/+27
| | | | | | | | Reland r310097 with a unit test fix for MS ABI build bots. Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310105
* Revert "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-27/+0
| | | | | | This reverts commit r310097. llvm-svn: 310099
* CFI: blacklist STL allocate() from unrelated-castsVlad Tsyrklevich2017-08-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously, STL allocators were blacklisted in compiler_rt's cfi_blacklist.txt because they mandated a cast from void* to T* before object initialization completed. This change moves that logic into the front end because C++ name mangling supports a substitution compression mechanism for symbols that makes it difficult to blacklist the mangled symbol for allocate() using a regular expression. Motivated by crbug.com/751385. Reviewers: pcc, kcc Reviewed By: pcc Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310097
* [OpenCL] Fix access qualifiers metadata for kernel arguments with typedefAlexey Sotkin2017-07-261-1/+4
| | | | | | | | Subscribers: cfe-commits, yaxunl, Anastasia Differential Revision: https://reviews.llvm.org/D35420 llvm-svn: 309155
* [ubsan] Improve diagnostics for return value checks (clang)Vedant Kumar2017-06-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes ubsan's nonnull return value diagnostics more precise, which makes the diagnostics more useful when there are multiple return statements in a function. Example: 1 |__attribute__((returns_nonnull)) char *foo() { 2 | if (...) { 3 | return expr_which_might_evaluate_to_null(); 4 | } else { 5 | return another_expr_which_might_evaluate_to_null(); 6 | } 7 |} // <- The current diagnostic always points here! runtime error: Null returned from Line 7, Column 2! With this patch, the diagnostic would point to either Line 3, Column 5 or Line 5, Column 5. This is done by emitting source location metadata for each return statement in a sanitized function. The runtime is passed a pointer to the appropriate metadata so that it can prepare and deduplicate reports. Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298 Differential Revision: https://reviews.llvm.org/D34299 llvm-svn: 306163
* [Clang] Handle interaction of -pg and no_instrument_function attribute.Manoj Gupta2017-06-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: Disable generation of counting-function attribute if no_instrument_function attribute is present in function. Interaction between -pg and no_instrument_function is the desired behavior and matches gcc as well. This is required for fixing a crash in Linux kernel when function tracing is enabled. Fixes PR33515. Reviewers: hfinkel, rengolin, srhines, hans Reviewed By: hfinkel Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34357 llvm-svn: 305728
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-3/+2
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* [CGDebugInfo] Finalize SubPrograms when we're done with themKeno Fischer2017-06-011-1/+1
| | | | | | | | | | | | | | | | | | `GenerateVarArgsThunk` in `CGVTables` clones a function before the frontend is done emitting the compilation unit. Because of the way that DIBuilder works, this means that the attached subprogram had incomplete (temporary) metadata. Cloning such metadata is semantically disallowed, but happened to work anyway due to bugs in the cloning logic. rL304226 attempted to fix up that logic, but in the process exposed the incorrect API use here and had to be reverted. To be able to fix this, I added a new method to DIBuilder in rL304467, to allow finalizing a subprogram independently of the entire compilation unit. Use that here, in preparation of re-applying rL304226. Reviewers: aprantl, dblaikie Differential Revision: https://reviews.llvm.org/D33705 llvm-svn: 304470
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-11/+13
| | | | | | | | | | | | | 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
* [OpenCL] Add intel_reqd_sub_group_size attribute supportXiuli Pan2017-05-041-12/+20
| | | | | | | | | | | | | | | | Summary: Add intel_reqd_sub_group_size attribute support as intel extension cl_intel_required_subgroup_size from https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt Reviewers: Anastasia, bader, hfinkel, pxli168 Reviewed By: Anastasia, bader, pxli168 Subscribers: cfe-commits, yaxunl Differential Revision: https://reviews.llvm.org/D30805 llvm-svn: 302125
* [ubsan] Reduce alignment checking of C++ object pointersVedant Kumar2017-04-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [OpenCL] Do not generate "kernel_arg_type_qual" metadata for non-pointer argsEgor Churaev2017-03-311-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: "kernel_arg_type_qual" metadata should contain const/volatile/restrict tags only for pointer types to match the corresponding requirement of the OpenCL specification. OpenCL 2.0 spec 5.9.3 Kernel Object Queries: CL_KERNEL_ARG_TYPE_VOLATILE is returned if the argument is a pointer and the referenced type is declared with the volatile qualifier. [...] Similarly, CL_KERNEL_ARG_TYPE_CONST is returned if the argument is a pointer and the referenced type is declared with the restrict or const qualifier. [...] CL_KERNEL_ARG_TYPE_RESTRICT will be returned if the pointer type is marked restrict. Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D31321 llvm-svn: 299192
* [msan] Turn off lifetime markers even when use after scope checking is on.Benjamin Kramer2017-03-311-4/+4
| | | | | | | | | Since r299174 use after scope checking is on by default. Even though msan doesn't check for use after scope it gets confused by the lifetime markers emitted for it, making unit tests fail. This is covered by ninja check-msan. llvm-svn: 299191
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Honor __unaligned in codegen for declarations and expressionsRoger Ferrer Ibanez2017-03-081-0/+2
| | | | | | | | | | | This patch honors the unaligned type qualifier (currently available through he keyword __unaligned and -fms-extensions) in CodeGen. In the current form the patch affects declarations and expressions. It does not affect fields of classes. Differential Revision: https://reviews.llvm.org/D30166 llvm-svn: 297276
* [XRay] [clang] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-0/+4
| | | | | | | | | | | | | | | | Summary: Functions with the "xray_log_args" attribute will tell LLVM to emit a special XRay sled for compiler-rt to copy any call arguments to your logging handler. Reviewers: dberris Reviewed By: dberris Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D29704 llvm-svn: 296999
* Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-0/+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-5/+0
| | | | | | | | 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-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-5/+0
| | | | | | | | | | 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-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MS] Fix C++ destructor thunk line info for a declarationReid Kleckner2017-02-081-1/+6
| | | | | | | | | | Sometimes the MS ABI needs to emit thunks for declarations that don't have bodies. Destructor thunks make calls to inlinable functions, so they need line info or LLVM will complain. Fixes PR31893 llvm-svn: 294465
* [X86] Teach Clang about -mfentry flagNirav Dave2017-01-311-2/+6
| | | | | | | | | | | | Replace mcount calls with calls to fentry. Reviewers: hfinkel, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28001 llvm-svn: 293649
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-1/+3
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* [OPENMP] Fix for PR31643: Clang crashes when compiling code on WindowsAlexey Bataev2017-01-201-2/+1
| | | | | | | | | | with SEH and openmp In some cituations (during codegen for Windows SEH constructs) CodeGenFunction instance may have CurFn equal to nullptr. OpenMP related code does not expect such situation during cleanup. llvm-svn: 292590
* [tsan] Do not report errors in __destroy_helper_block_Anna Zaks2017-01-131-3/+11
| | | | | | | | | | There is a synchronization point between the reference count of a block dropping to zero and it's destruction, which TSan does not observe. Do not report errors in the compiler-emitted block destroy method and everything called from it. This is similar to https://reviews.llvm.org/D25857 Differential Revision: https://reviews.llvm.org/D28387 llvm-svn: 291868
* Add a cc1 option to force disabling lifetime-markers emission from clangMehdi Amini2017-01-061-0/+3
| | | | | | | | Summary: This intended as a debugging/development flag only. Differential Revision: https://reviews.llvm.org/D28385 llvm-svn: 291300
* Add -f[no-]strict-return flag that can be used to avoid undefined behaviourAlex Lorenz2017-01-041-4/+23
| | | | | | | | | | | | | | | | | | | | | | | in non-void functions that fall off at the end without returning a value when compiling C++. Clang uses the new compiler flag to determine when it should treat control flow paths that fall off the end of a non-void function as unreachable. If -fno-strict-return is on, the code generator emits the ureachable and trap IR only when the function returns either a record type with a non-trivial destructor or another non-trivially copyable type. The primary goal of this flag is to avoid treating falling off the end of a non-void function as undefined behaviour. The burden of undefined behaviour is placed on the caller instead: if the caller ignores the returned value then the undefined behaviour is avoided. This kind of behaviour is useful in several cases, e.g. when compiling C code in C++ mode. rdar://13102603 Differential Revision: https://reviews.llvm.org/D27163 llvm-svn: 290960
* Cleanup the handling of noinline function attributes, -fno-inline,Chandler Carruth2016-12-231-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
* [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
* [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MDPekka Jaaskelainen2016-11-141-3/+19
| | | | | | | | | | | | | | | It doesn't make sense to use the target's address space ids in this context as this is metadata that should be referring to the "logical" OpenCL address spaces. For flat AS machines like all "CPUs" in general, the logical AS info gets lost as there's only one address space (0). This commit changes the logic such that we always use the SPIR address space ids for the argument metadata. It thus allows implementing the clGetKernelArgInfo() and the other detection needs. https://reviews.llvm.org/D26157 llvm-svn: 286819
OpenPOWER on IntegriCloud