summaryrefslogtreecommitdiffstats
path: root/clang/test
Commit message (Collapse)AuthorAgeFilesLines
* long double is double on OpenBSD/NetBSD/PPC.Brad Smith2019-02-111-0/+2
| | | | | | Patch by George Koehler. llvm-svn: 353656
* Fix test to pass on LLP64 targetsReid Kleckner2019-02-101-2/+2
| | | | llvm-svn: 353654
* Fix clang tests broken by r353547 that depend on InstrProfReid Kleckner2019-02-107-15/+15
| | | | llvm-svn: 353653
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-092-2/+2
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* [AMDGPU] Split dot-insts featureStanislav Mekhanoshin2019-02-092-15/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D57972 llvm-svn: 353588
* [analyzer] CStringSyntaxChecks: Fix an off-by-one error in the strlcat() check.Artem Dergachev2019-02-081-0/+2
| | | | | | | | | | | | oth strlcat and strlcpy cut off their safe bound for the argument value at sizeof(destination). There's no need to subtract 1 in only one of these cases. Differential Revision: https://reviews.llvm.org/D57981 rdar://problem/47873212 llvm-svn: 353583
* -gmodules: Don't emit incomplete breadcrumbs pointing to nonexistant PCM files.Adrian Prantl2019-02-081-0/+16
| | | | | | | | | | | | | | 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/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sema] Make string literal init an rvalue.Eli Friedman2019-02-083-5/+14
| | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Opt-in C Style Cast Checker for OSObject pointersGeorge Karpenkov2019-02-081-0/+39
| | | | | | Differential Revision: https://reviews.llvm.org/D57261 llvm-svn: 353566
* [X86] Add explicit alignment to __m128/__m128i/__m128d/etc. to allow ↵Craig Topper2019-02-081-0/+227
| | | | | | | | | | | | | | | | | | | | | | | matching of MSVC behavior with #pragma pack. Summary: With MSVC, #pragma pack is ignored when there is explicit alignment. This differs from gcc. Clang emulates this difference when compiling for Windows. It appears that MSVC and its headers consider the __m128/__m128i/__m128d/etc. types to be explicitly aligned and ignores #pragma pack for them. Since we don't have explicit alignment on them in our headers, we don't match the MSVC behavior here. This patch adds explicit alignment to match this behavior. I'm hoping this won't cause any problems when we're not emulating MSVC. But if someone knows of something that would be different we can swith to conditionally adding the alignment based on _MSC_VER. I had to add explicitly unaligned types as well so we could use them in the loadu/storeu intrinsics which use __attribute__(__packed__). Using the now explicitly aligned types wouldn't produce align 1 accesses when targeting Windows. Reviewers: rnk, erichkeane, spatel, RKSimon Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57961 llvm-svn: 353555
* [OPENMP]Delay emission of the error messages for the exceptions.Alexey Bataev2019-02-081-0/+13
| | | | | | | | | | Fixed diagnostic emission for the exceptions support in case of the compilation of OpenMP code for the devices. From now on, it uses delayed diagnostics mechanism, previously used for CUDA only. It allow to diagnose not allowed used of exceptions only in functions that are going to be codegen'ed. llvm-svn: 353542
* Revert "[OPENMP]Initial support for the delayed diagnostics."Alexey Bataev2019-02-081-13/+0
| | | | | | | This reverts commit r353540. Erroneously committed, need to fix the message and description. llvm-svn: 353541
* [OPENMP]Initial support for the delayed diagnostics.Alexey Bataev2019-02-081-0/+13
| | | | | | | | | It is important to delay the emission of the diagnostic messages for the functions unless it is proved that the function is going to be used on the device side. It is required to support compilation with some of the target-specific system headers. llvm-svn: 353540
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-0835-346/+344
| | | | | | | | | | | | | | | | | | | | | | | 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-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-42/+66
| | | | | | | | | | r344765 added those intrinsics, but used the wrong types. Patch by Mike Hommey Differential Revision: https://reviews.llvm.org/D57636 llvm-svn: 353493
* bpf: teach BPF driver about the new CPU "v3"Jiong Wang2019-02-071-1/+1
| | | | | | | | | This patch simply teach BPF driver about the new CPU "v3" introduced in LLVM backend. Acked-by: Yonghong Song <yhs@fb.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> llvm-svn: 353479
* [Sema][ObjC] Disallow non-trivial C struct fields in unions.Akira Hatanaka2019-02-071-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bug where clang doesn’t reject union fields of non-trivial C struct types. For example: ``` // This struct is non-trivial under ARC. struct S0 { id x; }; union U0 { struct S0 s0; // clang should reject this. struct S0 s1; // clang should reject this. }; void test(union U0 a) { // Previously, both 'a.s0.x' and 'a.s1.x' were released in this // function. } ``` rdar://problem/46677858 Differential Revision: https://reviews.llvm.org/D55659 llvm-svn: 353459
* [OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0Anastasia Stulova2019-02-072-59/+64
| | | | | | | | | | Valid OpenCL C code should still compile in C++ mode. This change enables extensions and OpenCL types. Differential Revision: https://reviews.llvm.org/D57824 llvm-svn: 353431
* Fix r350643 to limit COFF emission to <= 32 BYTES instead of BITS.Erich Keane2019-02-071-0/+3
| | | | | | | | | 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
* [clang-cl] support /Oy- on aarch64Martin Storsjo2019-02-071-0/+4
| | | | | | | | | | MSVC supports /Oy- on aarch64, so clang-cl should too. Patch by Nathan Froyd! Differential Revision: https://reviews.llvm.org/D57838 llvm-svn: 353402
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-072-2/+2
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* [analyzer] Canonicalize declarations within variable regions.Artem Dergachev2019-02-071-0/+15
| | | | | | | | | | | | | | | Memory region that correspond to a variable is identified by the variable's declaration and, in case of local variables, the stack frame it belongs to. The declaration needs to be canonical, otherwise we'd have two different memory regions that correspond to the same variable. Fix such bug for global variables with forward declarations and assert that no other problems of this kind happen. Differential Revision: https://reviews.llvm.org/D57619 llvm-svn: 353353
* Revert "[analyzer] Remove the "postponed" hack, deal with derived symbols..."Artem Dergachev2019-02-062-0/+43
| | | | | | | | | | | | | | This reverts commit r341722. The "postponed" mechanism turns out to be necessary in order to handle situations when a symbolic region is only kept alive by implicit bindings in the Store. Otherwise the region is never scanned by the Store's worklist and the binding gets dropped despite being live, as demonstrated by the newly added tests. Differential Revision: https://reviews.llvm.org/D57554 llvm-svn: 353350
* [COFF, ARM64] Add ARM64 support for MS intrinsic _fastfailTom Tan2019-02-061-3/+2
| | | | | | | | | | 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
* [WebAssembly] Add atomics target optionHeejin Ahn2019-02-061-3/+14
| | | | | | | | | | | | Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57798 llvm-svn: 353260
* Fix MSVC constructor call extension after b92d290e48e9 (r353181).James Y Knight2019-02-061-9/+18
| | | | | | | | | | | | | | | | | | | | 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
* [modules] Fix handling of initializers for templated global variables.Richard Smith2019-02-051-0/+242
| | | | | | | | | | | | | | | For global variables with unordered initialization that are instantiated within a module, we previously did not emit the global (or its initializer) at all unless it was used in the importing translation unit (and sometimes not even then!), leading to misbehavior and link errors. We now emit the initializer for an instantiated global variable with unordered initialization with side-effects in a module into every translation unit that imports the module. This is unfortunate, but mostly matches the behavior of a non-modular compilation and seems to be the best that we can reasonably do. llvm-svn: 353240
* [Preprocessor] Add a note with framework location for "file not found" error.Volodymyr Sapsai2019-02-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | When a framework with the same name is available at multiple framework search paths, we use the first matching location. If a framework at this location doesn't have all the headers, it can be confusing for developers because they see only an error `'Foo/Foo.h' file not found`, can find the complete framework with required header, and don't know the incomplete framework was used instead. Add a note explaining a framework without required header was found. Also mention framework directory path to make it easier to find the incomplete framework. rdar://problem/39246514 Reviewers: arphaman, erik.pilkington, jkorous Reviewed By: jkorous Subscribers: jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56561 llvm-svn: 353231
* [analyzer] [RetainCountChecker] Bugfix: in non-OSObject-mode, do not track ↵George Karpenkov2019-02-051-1/+19
| | | | | | | | CXX method calls Differential Revision: https://reviews.llvm.org/D57782 llvm-svn: 353227
* Do not use frame pointer by default for MSP430Anton Korobeynikov2019-02-051-0/+19
| | | | | | | | | | | This is suggested by 3.3.9 of MSP430 EABI document. We do allow user to manually enable frame pointer. GCC toolchain uses the same behavior. Patch by Dmitry Mikushev! Differential Revision: https://reviews.llvm.org/D56925 llvm-svn: 353212
* [DEBUG_INFO][NVPTX] Generate correct data about variable address class.Alexey Bataev2019-02-051-0/+25
| | | | | | | | | | | | | | | | | | | | | 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
* [OPENMP] issue error messages for multiple teams contructs in a target constructKelvin Li2019-02-051-0/+14
| | | | | | | | | | | | | | | | The fix is to issue error messages if there are more than one teams construct inside a target constructs. #pragma omp target { #pragma omp teams { ... } #pragma omp teams { ... } } llvm-svn: 353186
* [opaque pointer types] Fix the CallInfo passed to EmitCall in someJames Y Knight2019-02-051-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Explicitly add -std=c++14 option to tests that rely on the C++14 defaultNemanja Ivanovic2019-02-0514-21/+21
| | | | | | | | | | | When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets the default standard to something other than C++14, there are a number of lit tests that fail as they rely on the C++14 default. This patch just adds the language standard option explicitly to such test cases. Differential revision: https://reviews.llvm.org/D57581 llvm-svn: 353163
* Fix ICE on reference binding with mismatching addr spaces.Anastasia Stulova2019-02-051-0/+14
| | | | | | | | | | | | When we attempt to add an addr space qual to a type already qualified by an addr space ICE is triggered. Before creating a type with new address space, remove the old addr space. Fixing PR38614! Differential Revision: https://reviews.llvm.org/D57524 llvm-svn: 353160
* [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-043-1/+41
| | | | | | | | | | | | | 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
* [SemaObjC] Don't infer the availabilty of +new from -init if the receiver ↵Erik Pilkington2019-02-041-0/+13
| | | | | | | | | | has Class type rdar://47713266 Differential revision: https://reviews.llvm.org/D57712 llvm-svn: 353115
* Generalize pthread callback test caseJohannes Doerfert2019-02-041-8/+16
| | | | | | Changes suggested by Eli Friedman <efriedma@quicinc.com> llvm-svn: 353088
* [OpenMP] Adding support to the mutexinoutset dep-typeSergi Mateo Bellido2019-02-0415-68/+107
| | | | | | | | | | | 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
* [ASTDump] Add a flag indicating whether a CXXThisExpr is implicitBruno Ricci2019-02-033-4/+4
| | | | | | | | | | | There is currently no way to distinguish implicit from explicit CXXThisExpr in the AST dump output. Differential Revision: https://reviews.llvm.org/D57649 Reviewed By: steveire llvm-svn: 353003
* Hot fix two test regressions (%T vs %t)David Zarzycki2019-02-032-2/+2
| | | | | | | | | | | | | Different Unix "errno" values are returned for the following scenarios: $ echo test > /tmp/existingFile/impossibleDir/impossibleFile "Not a directory" $ echo test > /tmp/nonexistentDir/impossibleFile "No such file or directory" This fixes the regression introduced by r352971 / D57592. llvm-svn: 352996
* [objc-gnustep] Fix encoding of ivar size for _Bool.David Chisnall2019-02-031-2/+4
| | | | llvm-svn: 352995
* Correct test my *really really* overaligning a type.Eric Fiselier2019-02-031-2/+2
| | | | llvm-svn: 352983
* Fix handling of usual deallocation functions in various configuratios.Eric Fiselier2019-02-032-5/+77
| | | | | | | | | | | | | Clang allows users to enable or disable various types of allocation and deallocation regardless of the C++ dialect. When extended new/delete overloads are enabled in older dialects, we need to treat them as if they're usual. Also, disabling one usual deallocation form shouldn't disable any others. For example, disabling aligned allocation in C++2a should have no effect on destroying delete. llvm-svn: 352980
* Replace uses of %T with %t in from previous frontend test differentialNico Weber2019-02-022-2/+2
| | | | | | | | | | | | | | | After committing a change I had made to a few frontend tests, it was pointed out to me that %T is being deprecated in LLVM in favor of %t. This change simply converts usages of %T to %t while maintaining the integrity of the test. Previous revision where this discussion took place: https://reviews.llvm.org/D50563 Differential Revision: https://reviews.llvm.org/D57592 Patch from Justice Adams <justice.adams@sony.com>! llvm-svn: 352971
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-021-0/+440
| | | | | | | | | | | | | | | | | | | uninitialized fields This patch is an implementation of the ideas discussed on the mailing list[1]. The idea is to somewhat heuristically guess whether the field that was confirmed to be uninitialized is actually guarded with ifs, asserts, switch/cases and so on. Since this is a syntactic check, it is very much prone to drastically reduce the amount of reports the checker emits. The reports however that do not get filtered out though have greater likelihood of them manifesting into actual runtime errors. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html Differential Revision: https://reviews.llvm.org/D51866 llvm-svn: 352959
* [Sema][ObjC] Allow declaring ObjC pointer members with non-trivialAkira Hatanaka2019-02-022-2/+159
| | | | | | | | | | | | | | | ownership qualifications in C++ unions under ARC. An ObjC pointer member with non-trivial ownership qualifications causes all of the defaulted special functions of the enclosing union to be defined as deleted, except when the member has an in-class initializer, the default constructor isn't defined as deleted. rdar://problem/34213306 Differential Revision: https://reviews.llvm.org/D57438 llvm-svn: 352949
OpenPOWER on IntegriCloud