summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [AMDGPU] Require at least protected visibility for certain symbolsScott Linder2019-02-122-0/+18
| | | | | | | | | This allows the global visibility controls to be restrictive while still populating the dynamic symbol table where required. Differential Revision: https://reviews.llvm.org/D56871 llvm-svn: 353870
* Add a new attribute, fortify_stdlibErik Pilkington2019-02-112-0/+88
| | | | | | | | | | | | | | | | | | | | | | This attribute applies to declarations of C stdlib functions (sprintf, memcpy...) that have known fortified variants (__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit calls to the fortified variant functions instead of calls to the defaults. In GCC, this is done by adding gnu_inline-style wrapper functions, but that doesn't work for us for variadic functions because we don't support __builtin_va_arg_pack (and have no intention to). This attribute takes two arguments, the first is 'type' argument passed through to __builtin_object_size, and the second is a flag argument that gets passed through to the variadic checking variants. rdar://47905754 Differential revision: https://reviews.llvm.org/D57918 llvm-svn: 353765
* [CodeGen] Set construction vtable visibility after creating initializerPetr Hosek2019-02-111-1/+5
| | | | | | | | | | We must only set the construction vtable visibility after we create the vtable initializer, otherwise the global value will be treated as declaration rather than definition and the visibility won't be set. Differential Revision: https://reviews.llvm.org/D58010 llvm-svn: 353742
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-0919-338/+165
| | | | | | | | | | | | | | The various EltSize, Offset, DataLayout, and StructLayout arguments are all computable from the Address's element type and the DataLayout which the CGBuilder already has access to. After having previously asserted that the computed values are the same as those passed in, now remove the redundant arguments from CGBuilder's Create*GEP functions. Differential Revision: https://reviews.llvm.org/D57767 llvm-svn: 353629
* -gmodules: Don't emit incomplete breadcrumbs pointing to nonexistant PCM files.Adrian Prantl2019-02-081-1/+9
| | | | | | | | | | | | | | When a module name is specified as -fmodule-name, that module gets a clang::Module object, but it won't actually be built or imported; it will be textual. CGDebugInfo wouldn't detect this and them emit a DICompileUnit that had a hash but no name and that confused both dsymutil, LLDB, and myself. rdar://problem/47926508 Differential Revision: https://reviews.llvm.org/D57976 llvm-svn: 353578
* [CodeGen][ObjC] Fix assert on calling `__builtin_constant_p` with ObjC objects.Volodymyr Sapsai2019-02-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are calling `__builtin_constant_p` with ObjC objects of different classes, we hit the assertion > Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file include/llvm/Support/Casting.h, line 254. It happens because LLVM types for `ObjCInterfaceType` are opaque and have no name (see `CodeGenTypes::ConvertType`). As the result, for different ObjC classes we have different `is_constant` intrinsics with the same name `llvm.is.constant.p0s_s`. When we try to reuse an intrinsic with the same name, we fail because of type mismatch. Fix by bitcasting `ObjCObjectPointerType` to `id` prior to passing as an argument to `__builtin_constant_p`. This results in using intrinsic `llvm.is.constant.p0i8` and correct types. rdar://problem/47499250 Reviewers: rjmccall, ahatanak, void Reviewed By: void, ahatanak Subscribers: ddunbar, jkorous, hans, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D57427 llvm-svn: 353577
* [CodeGen][NFC] Update comments in CGExprConstant.cpp.Eli Friedman2019-02-081-5/+8
| | | | llvm-svn: 353571
* [Sema] Make string literal init an rvalue.Eli Friedman2019-02-081-10/+0
| | | | | | | | | | | | | | | | | | | | | | | This allows substantially simplifying the expression evaluation code, because we don't have to special-case lvalues which are actually string literal initialization. This currently throws away an optimization where we would avoid creating an array APValue for string literal initialization. If we really want to optimize this case, we should fix APValue so it can store simple arrays more efficiently, like llvm::ConstantDataArray. This shouldn't affect the memory usage for other string literals. (Not sure if this is a blocker; I don't think string literal init is common enough for this to be a serious issue, but I could be wrong.) The change to test/CodeGenObjC/encode-test.m is a weird side-effect of these changes: we currently don't constant-evaluate arrays in C, so the strlen call shouldn't be folded, but lvalue string init managed to get around that check. I this this is fine. Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 . llvm-svn: 353569
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-084-7/+56
| | | | | | | | | | | | | | | | | | | | | | | Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
* Variable auto-init: fix __block initializationJF Bastien2019-02-081-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Automatic initialization [1] of __block variables was trampling over the block's headers after they'd been initialized, which caused self-init usage to crash, such as here: typedef struct XYZ { void (^block)(); } *xyz_t; __attribute__((noinline)) xyz_t create(void (^block)()) { xyz_t myself = malloc(sizeof(struct XYZ)); myself->block = block; return myself; } int main() { __block xyz_t captured = create(^(){ (void)captured; }); } This type of code shouldn't be broken by variable auto-init, even if it's sketchy. [1] With -ftrivial-auto-var-init=pattern <rdar://problem/47798396> Reviewers: rjmccall, pcc, kcc Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57797 llvm-svn: 353495
* [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusRegEli Friedman2019-02-081-4/+1
| | | | | | | | | | r344765 added those intrinsics, but used the wrong types. Patch by Mike Hommey Differential Revision: https://reviews.llvm.org/D57636 llvm-svn: 353493
* [NFC] Variable auto-init: use getAsVariableArrayType helperJF Bastien2019-02-081-2/+1
| | | | | | As suggested by @rjmccall in D57797. llvm-svn: 353490
* Fix r350643 to limit COFF emission to <= 32 BYTES instead of BITS.Erich Keane2019-02-071-3/+5
| | | | | | | | | The patch in r350643 incorrectly sets the COFF emission based on bits instead of bytes. This patch converts the 32 via CharUnits to bits to compare the correct values. Change-Id: Icf38a16470ad5ae3531374969c033557ddb0d323 llvm-svn: 353411
* [opaque pointer types] Make EmitCall pass Function Types toJames Y Knight2019-02-072-26/+33
| | | | | | | | | | | | | | CreateCall/Invoke. Also, remove the getFunctionType() function from CGCallee, since it accesses the pointee type of the value. The only use was in EmitCall, so just inline it into the debug assertion. This is the last of the changes for Call and Invoke in clang. Differential Revision: https://reviews.llvm.org/D57804 llvm-svn: 353356
* [opaque pointer types] Pass through function types for TLSJames Y Knight2019-02-078-44/+62
| | | | | | | | initialization and global destructor calls. Differential Revision: https://reviews.llvm.org/D57801 llvm-svn: 353355
* [COFF, ARM64] Add ARM64 support for MS intrinsic _fastfailTom Tan2019-02-061-0/+3
| | | | | | | | | | The MSDN document was also updated to reflect this, but it probably will take a few days to show in below link. https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail Differential Revision: https://reviews.llvm.org/D57631 llvm-svn: 353337
* 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
* Basic CUDA-10 support.Artem Belevich2019-02-051-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D57771 llvm-svn: 353232
* Fix a missing word in commentAdrian Prantl2019-02-051-2/+2
| | | | llvm-svn: 353219
* [DEBUG_INFO][NVPTX] Generate correct data about variable address class.Alexey Bataev2019-02-051-0/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Added ability to generate correct debug info data about the variable address class. Currently, for all the locals and globals the default values are used, ADDR_local_space(6) for locals and ADDR_global_space(5) for globals. The values are taken from the table in https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf. We need to emit correct data for address classes of, at least, shared and constant globals. Currently, all these variables are treated by the cuda-gdb debugger as the variables in the global address space and, thus, it require manual data type casting. Reviewers: echristo, probinson Subscribers: jholewinski, aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D57162 llvm-svn: 353204
* [opaque pointer types] More trivial changes to pass FunctionType to CallInst.James Y Knight2019-02-056-22/+28
| | | | | | | | Change various functions to use FunctionCallee or Function*. Pass function type through __builtin_dump_struct's dumpRecord helper. llvm-svn: 353199
* Minor cleanup: remove CGBuild::CreateConst*ByteGEP overloads taking a Value*.James Y Knight2019-02-052-21/+7
| | | | llvm-svn: 353197
* [opaque pointer types] Pass function types for runtime function calls.James Y Knight2019-02-0528-573/+588
| | | | | | | | | | | | | Emit{Nounwind,}RuntimeCall{,OrInvoke} have been modified to take a FunctionCallee as an argument, and CreateRuntimeFunction has been modified to return a FunctionCallee. All callers have been updated. Additionally, CreateBuiltinFunction is removed, as it was redundant with CreateRuntimeFunction after some previous changes. Differential Revision: https://reviews.llvm.org/D57668 llvm-svn: 353184
* [opaque pointer types] Fix the CallInfo passed to EmitCall in someJames Y Knight2019-02-055-40/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sanitizers] UBSan unreachable incompatible with Kernel ASanJulian Lettner2019-02-041-1/+2
| | | | | | | | | | | | | | | | Summary: This is a follow up for https://reviews.llvm.org/D57278. The previous revision should have also included Kernel ASan. rdar://problem/40723397 Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57711 llvm-svn: 353120
* [OBJC] Add attribute to mark Objective C class as non-lazyJoe Daniels2019-02-041-3/+4
| | | | | | | | | | | | | A non-lazy class will be initialized eagerly when the Objective-C runtime is loaded. This is required for certain system classes which have instances allocated in non-standard ways, such as the classes for blocks and constant strings. Adding this attribute is essentially equivalent to providing a trivial +load method but avoids the (fairly small) load-time overheads associated with defining and calling such a method. Differential Revision: https://reviews.llvm.org/D56555 llvm-svn: 353116
* [NewPM][MSan] Add Options HandlingPhilip Pfaffe2019-02-041-2/+3
| | | | | | | | | | | | | | Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
* [OpenMP] Adding support to the mutexinoutset dep-typeSergi Mateo Bellido2019-02-041-1/+4
| | | | | | | | | | | Summary: this commit adds support to a new dependence type introduced in OpenMP 5.0. The LLVM OpenMP RTL already supports this feature, so we only need to modify CLANG to take advantage of them. Differential Revision: https://reviews.llvm.org/D57576 llvm-svn: 353018
* [opaque pointer types] Trivial changes towards CallInst requiringJames Y Knight2019-02-0310-109/+112
| | | | | | explicit function types. llvm-svn: 353009
* [objc-gnustep] Fix encoding of ivar size for _Bool.David Chisnall2019-02-031-3/+1
| | | | llvm-svn: 352995
* [NewPM] Add support for new-PM plugins to clangPhilip Pfaffe2019-02-021-0/+12
| | | | | | | | | | | | | | | Summary: This adds support for new-PM plugin loading to clang. The option `-fpass-plugin=` may be used to specify a dynamic shared object file that adheres to the PassPlugin API. Tested: created simple plugin that registers an EP callback; with optimization level > 0, the pass is run as expected. Committed on behalf of Marco Elver Differential Revision: https://reviews.llvm.org/D56935 llvm-svn: 352972
* [ASan] Do not instrument other runtime functions with `__asan_handle_no_return`Julian Lettner2019-02-021-2/+2
| | | | | | | | | | | | | | Summary: Currently, ASan inserts a call to `__asan_handle_no_return` before every `noreturn` function call/invoke. This is unnecessary for calls to other runtime funtions. This patch changes ASan to skip instrumentation for functions calls marked with `!nosanitize` metadata. Reviewers: TODO Differential Revision: https://reviews.llvm.org/D57489 llvm-svn: 352948
* Remove redundant FunctionDecl argument from a couple functions.James Y Knight2019-02-028-43/+28
| | | | | | | | | | | | | | | | | | 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
* [WebAssembly] Add an import_field function attributeDan Gohman2019-02-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | This is similar to import_module, but sets the import field name instead. By default, the import field name is the same as the C/asm/.o symbol name. However, there are situations where it's useful to have it be different. For example, suppose I have a wasm API with a module named "pwsix" and a field named "read". There's no risk of namespace collisions with user code at the wasm level because the generic name "read" is qualified by the module name "pwsix". However in the C/asm/.o namespaces, the module name is not used, so if I have a global function named "read", it is intruding on the user's namespace. With the import_field module, I can declare my function (in libc) to be "__read", and then set the wasm import module to be "pwsix" and the wasm import field to be "read". So at the C/asm/.o levels, my symbol is outside the user namespace. Differential Revision: https://reviews.llvm.org/D57602 llvm-svn: 352930
* Factor out duplication between ExprIterator and ConstExprIterator.Richard Smith2019-02-011-1/+1
| | | | | | | This also exposes a more general iterator cast mechanism suitable for use in http://reviews.llvm.org/D56571. llvm-svn: 352925
* [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.Michael Kruse2019-02-015-0/+29
| | | | | | | | | | | | | | | | | This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-02-012-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every unreachable instruction. However, the optimizer will remove code after calls to functions marked with noreturn. To avoid this UBSan removes noreturn from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to _asan_handle_no_return before noreturn functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* longjmp (longjmp itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the noreturn attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: Clang-CodeGen now directly insert calls to `__asan_handle_no_return` when a call to a noreturn function is encountered and both UBsan-unreachable and ASan are enabled. This allows UBSan to continue removing the noreturn attribute from functions without any changes to the ASan pass. Previously generated code: ``` call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable ``` Generated code (for now): ``` call void @__asan_handle_no_return call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable ``` rdar://problem/40723397 Reviewers: delcypher, eugenis, vsk Differential Revision: https://reviews.llvm.org/D57278 > llvm-svn: 352690 llvm-svn: 352829
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-3/+2
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [CUDA] add support for the new kernel launch API in CUDA-9.2+.Artem Belevich2019-01-311-4/+106
| | | | | | | | | | | | | Instead of calling CUDA runtime to arrange function arguments, the new API constructs arguments in a local array and the kernels are launched with __cudaLaunchKernel(). The old API has been deprecated and is expected to go away in the next CUDA release. Differential Revision: https://reviews.llvm.org/D57488 llvm-svn: 352799
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Eric Liu2019-01-312-15/+2
| | | | | | | | | presence of `noreturn` calls" This reverts commit r352690. This causes clang to crash. Sent reproducer to the author in the orginal commit. llvm-svn: 352755
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-302-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every unreachable instruction. However, the optimizer will remove code after calls to functions marked with noreturn. To avoid this UBSan removes noreturn from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to _asan_handle_no_return before noreturn functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* longjmp (longjmp itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the noreturn attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: Clang-CodeGen now directly insert calls to `__asan_handle_no_return` when a call to a noreturn function is encountered and both UBsan-unreachable and ASan are enabled. This allows UBSan to continue removing the noreturn attribute from functions without any changes to the ASan pass. Previously generated code: ``` call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable ``` Generated code (for now): ``` call void @__asan_handle_no_return call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable ``` rdar://problem/40723397 Reviewers: delcypher, eugenis, vsk Differential Revision: https://reviews.llvm.org/D57278 llvm-svn: 352690
* [CodeGenObjC] Handle exceptions when calling objc_alloc or objc_allocWithZoneErik Pilkington2019-01-301-11/+18
| | | | | | | | | | | | objc_alloc and objc_allocWithZone may throw exceptions if the underlying method does. If we're in a @try block, then make sure we emit an invoke instead of a call. rdar://47610407 Differential revision: https://reviews.llvm.org/D57476 llvm-svn: 352687
* [OPENMP]Fix PR40536: Do not emit __kmpc_push_target_tripcount if notAlexey Bataev2019-01-301-2/+3
| | | | | | | | | | required. Function __kmpc_push_target_tripcount should be emitted only if the offloading entry is going to be emitted (for use in tgt_target... functions). Otherwise, it should not be emitted. llvm-svn: 352669
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-303-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-302-2/+4
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* Cleanup: replace uses of CallSite with CallBase.James Y Knight2019-01-3020-134/+108
| | | | llvm-svn: 352595
* Adjust documentation for git migration.James Y Knight2019-01-291-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* AMDGPU: Add ds append/consume builtinsMatt Arsenault2019-01-281-0/+8
| | | | llvm-svn: 352443
OpenPOWER on IntegriCloud