summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Do not generate calls to fentry with __attribute__((no_instrument_function))Manoj Gupta2018-03-021-4/+6
| | | | | | | | | | | | | | | | | | | Summary: Currently only calls to mcount were suppressed with no_instrument_function attribute. Linux kernel requires that calls to fentry should also not be generated. This is an extended fix for PR PR33515. Reviewers: hfinkel, rengolin, srhines, rnk, rsmith, rjmccall, hans Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43995 llvm-svn: 326639
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-2/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* Recommit rL323952: [DebugInfo] Enable debug information for C99 VLA types.Sander de Smalen2018-02-031-11/+22
| | | | | | Fixed build issue when building with g++-4.8 (specialization after instantiation). llvm-svn: 324173
* Reverting patch rL323952 due to build errors that ISander de Smalen2018-02-011-22/+11
| | | | | | haven't encountered in local builds. llvm-svn: 323956
* [DebugInfo] Enable debug information for C99 VLA typesSander de Smalen2018-02-011-11/+22
| | | | | | | | | | | | | | | | | | | | | Summary: This patch enables debugging of C99 VLA types by generating more precise LLVM Debug metadata, using the extended DISubrange 'count' field that takes a DIVariable. This should implement: Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's) https://bugs.llvm.org/show_bug.cgi?id=30553 Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D41698 llvm-svn: 323952
* Allocate and access NormalCleanupDest with the natural alignment of i32.John McCall2018-01-121-4/+5
| | | | | | | | | This alignment can be less than 4 on certain embedded targets, which may not even be able to deal with 4-byte alignment on the stack. Patch by Jacob Young! llvm-svn: 322406
* Added Control Flow Protection FlagOren Ben Simhon2018-01-091-1/+2
| | | | | | | | | | Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc. For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions. Differential Revision: https://reviews.llvm.org/D40478 Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea llvm-svn: 322063
* Implement Attribute Target MultiVersioningErich Keane2018-01-081-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* No -fsanitize=function warning when calling noexcept function through ↵Stephan Bergmann2018-01-051-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | non-noexcept pointer in C++17 As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/ #!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non- noexcept pointer is undefined behavior?", such a call should not be UB. However, Clang currently warns about it. This change removes exception specifications from the function types recorded for -fsanitize=function, both in the functions themselves and at the call sites. That means that calling a non-noexcept function through a noexcept pointer will also not be flagged as UB. In the review of this change, that was deemed acceptable, at least for now. (See the "TODO" in compiler-rt test/ubsan/TestCases/TypeCheck/Function/function.cpp.) To remove exception specifications from types, the existing internal ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places otherwise unrelated to this change have been adapted to call it, too. This is the cfe part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40720 llvm-svn: 321859
* [WinEH] Allow for multiple terminatepadsReid Kleckner2018-01-021-0/+3
| | | | | | | | | Fixes verifier errors with Windows EH and OpenMP, which injects a terminate scope around parallel blocks. Fixes PR35778 llvm-svn: 321676
* [Driver, CodeGen] pass through and apply -fassociative-mathSanjay Patel2017-12-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math. This was mostly already done - we just need to translate the flag as a codegen option. The test file is complicated because there are many potential combinations of flags here. Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math. 2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and corresponding test. For the motivating example from PR27372: float foo(float a, float x) { return ((a + x) - x); } $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub' %add = fadd nnan ninf nsz arcp contract float %0, %1 %sub = fsub nnan ninf nsz arcp contract float %add, %2 So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch). This case now works as expected end-to-end although the underlying logic is still wrong: $ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example: $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd %add = fadd reassoc float %0, %1 $ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm addss %xmm1, %xmm0 subss %xmm1, %xmm0 Differential Revision: https://reviews.llvm.org/D39812 llvm-svn: 320920
* [OPENMP] Codegen `declare simd` for function declarations.Alexey Bataev2017-12-151-4/+0
| | | | | | | Previously the attributes were emitted only for function definitions. Patch adds emission of the attributes for function declarations. llvm-svn: 320826
* Hardware-assisted AddressSanitizer (clang part).Evgeniy Stepanov2017-12-091-0/+2
| | | | | | | | | | | | | | Summary: Driver, frontend and LLVM codegen for HWASan. A clone of ASan, basically. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D40936 llvm-svn: 320232
* [XRay][clang] Introduce -fxray-always-emit-customeventsDean Michael Berris2017-11-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-emit-customevents flag instructs clang to always emit the LLVM IR for calls to the `__xray_customevent(...)` built-in function. The default behaviour currently respects whether the function has an `[[clang::xray_never_instrument]]` attribute, and thus not lower the appropriate IR code for the custom event built-in. This change allows users calling through to the `__xray_customevent(...)` built-in to always see those calls lowered to the corresponding LLVM IR to lay down instrumentation points for these custom event calls. Using this flag enables us to emit even just the user-provided custom events even while never instrumenting the start/end of the function where they appear. This is useful in cases where "phase markers" using __xray_customevent(...) can have very few instructions, must never be instrumented when entered/exited. Reviewers: rnk, dblaikie, kpw Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40601 llvm-svn: 319388
* Add -finstrument-function-entry-bare flagHans Wennborg2017-11-211-9/+15
| | | | | | | | | | | | | | | | | This is an instrumentation flag that's similar to -finstrument-functions, but it only inserts calls on function entry, the calls are inserted post-inlining, and they don't take any arugments. This is intended for users who want to instrument function entry with minimal overhead. (-pg would be another alternative, but forces frame pointer emission and affects link flags, so is probably best left alone to be used for generating gcov data.) Differential revision: https://reviews.llvm.org/D40276 llvm-svn: 318785
* Switch -mcount and -finstrument-functions to emit EnterExitInstrumenter ↵Hans Wennborg2017-11-141-32/+18
| | | | | | | | | | | | | | | | attributes This updates -mcount to use the new attribute names (LLVM r318195), and switches over -finstrument-functions to also use these attributes rather than inserting instrumentation in the frontend. It also adds a new flag, -finstrument-functions-after-inlining, which makes the cygprofile instrumentation get inserted after inlining rather than before. Differential Revision: https://reviews.llvm.org/D39331 llvm-svn: 318199
* [coroutines] Promote cleanup.dest.slot allocas to registers to avoid storing ↵Gor Nishanov2017-11-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | it in the coroutine frame Summary: We don't want to store cleanup dest slot saved into the coroutine frame (as some of the cleanup code may access them after coroutine frame destroyed). This is an alternative to https://reviews.llvm.org/D37093 It is possible to do this for all functions, but, cursory check showed that in -O0, we get slightly longer function (by 1-3 instructions), thus, we are only limiting cleanup.dest.slot elimination to coroutines. Reviewers: rjmccall, hfinkel, eric_niebler Reviewed By: eric_niebler Subscribers: EricWF, cfe-commits Differential Revision: https://reviews.llvm.org/D39768 llvm-svn: 317981
* [CodeGen] match new fast-math-flag method: isFast()Sanjay Patel2017-11-061-1/+1
| | | | | | | | This corresponds to LLVM commiti r317488: If that commit is reverted, this commit will also need to be reverted. llvm-svn: 317489
* [CodeGen] Propagate may-alias'ness of lvalues with TBAA infoIvan A. Kosarev2017-10-311-2/+2
| | | | | | | | | | | | | This patch fixes various places in clang to propagate may-alias TBAA access descriptors during construction of lvalues, thus eliminating the need for the LValueBaseInfo::MayAlias flag. This is part of D38126 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D39008 llvm-svn: 316988
* [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-171-3/+3
| | | | | | | | base info Differential Revision: https://reviews.llvm.org/D38796 llvm-svn: 315984
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* [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
OpenPOWER on IntegriCloud