summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [clang-cl] support /Oy- on aarch64Martin Storsjo2019-02-071-4/+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-074-852/+21
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* Got rid of the `Z3ConstraintManager` classMikhail R. Gadelha2019-02-071-16/+1
| | | | | | | | | | Now, instead of passing the reference to a shared_ptr, we pass the shared_ptr instead. I've also removed the check if Z3 is present in CreateZ3ConstraintManager as this function already calls CreateZ3Solver that performs the exactly same check. Differential Revision: https://reviews.llvm.org/D54976 llvm-svn: 353371
* Generalised the SMT state constraintsMikhail R. Gadelha2019-02-071-26/+36
| | | | | | | | | | | | | | This patch moves the ConstraintSMT definition to the SMTConstraintManager header to make it easier to move the Z3 backend around. We achieve this by not using shared_ptr anymore, as llvm::ImmutableSet doesn't seem to like it. The solver specific exprs and sorts are cached in the Z3Solver object now and we move pointers to those objects around. As a nice side-effect, SMTConstraintManager doesn't have to be a template anymore. Yay! Differential Revision: https://reviews.llvm.org/D54975 llvm-svn: 353370
* [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
* [analyzer] Canonicalize declarations within variable regions.Artem Dergachev2019-02-071-0/+2
| | | | | | | | | | | | | | | 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-061-40/+20
| | | | | | | | | | | | | | 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-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
* Test commit. NFCPatrick Lyster2019-02-061-1/+1
| | | | llvm-svn: 353320
* Switch to cantFail(), since it does the same assertion.Stephen Hines2019-02-061-6/+5
| | | | | | | | | | | | Reviewers: cfe-commits, lhames Reviewed By: lhames Subscribers: hintonda, klimek, pirama Differential Revision: https://reviews.llvm.org/D36806 llvm-svn: 353318
* [CMake] Unify scripts for generating VCS headersPetr Hosek2019-02-062-39/+31
| | | | | | | | | | | | | | | | | Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang and lldb. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM, Clang and lldb, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 353268
* [WebAssembly] Add atomics target optionHeejin Ahn2019-02-062-0/+15
| | | | | | | | | | | | 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-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
* [modules] Fix handling of initializers for templated global variables.Richard Smith2019-02-054-2/+21
| | | | | | | | | | | | | | | 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
* Basic CUDA-10 support.Artem Belevich2019-02-054-2/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D57771 llvm-svn: 353232
* [Preprocessor] Add a note with framework location for "file not found" error.Volodymyr Sapsai2019-02-058-26/+55
| | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+6
| | | | | | | | CXX method calls Differential Revision: https://reviews.llvm.org/D57782 llvm-svn: 353227
* Fix a missing word in commentAdrian Prantl2019-02-051-2/+2
| | | | llvm-svn: 353219
* Do not use frame pointer by default for MSP430Anton Korobeynikov2019-02-051-0/+1
| | | | | | | | | | | 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-052-0/+32
| | | | | | | | | | | | | | | | | | | | | 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
* [OPENMP] issue error messages for multiple teams contructs in a target constructKelvin Li2019-02-051-1/+3
| | | | | | | | | | | | | | | | 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] 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-056-42/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix ICE on reference binding with mismatching addr spaces.Anastasia Stulova2019-02-051-10/+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
* [X86] Change MS inline asm clobber list filter to check for 'fpsr' instead ↵Craig Topper2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | of 'fpsw' after D57641. Summary: The backend used to print the x87 FPSW register as 'fpsw', but gcc inline asm uses 'fpsr'. After D57641, the backend now uses 'fpsr' to match. Reviewers: rnk Reviewed By: rnk Subscribers: eraman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57642 llvm-svn: 353142
* [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-042-3/+7
| | | | | | | | | | | | | 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-4/+3
| | | | | | | | | | has Class type rdar://47713266 Differential revision: https://reviews.llvm.org/D57712 llvm-svn: 353115
* [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
* [clang-format] Fix breaking of qualified operatorKrasimir Georgiev2019-02-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: From https://bugs.llvm.org/show_bug.cgi?id=40516 ``` $ cat a.cpp const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() { // do stuff } const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() { // do stuff } $ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp const NamespaceName::VeryLongClassName & NamespaceName::VeryLongClassName::myFunction() { // do stuff } const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName:: operator++() { // do stuff } ``` What was happening is that the split penalty before `operator` was being set to a smaller value by a prior if block. Moved checks around to fix this and added a regression test. Reviewers: djasper Reviewed By: djasper Tags: #clang Differential Revision: https://reviews.llvm.org/D57604 llvm-svn: 353033
* [clang] Add getCommentHandler to PreambleCallbacksKadir Cetinkaya2019-02-041-0/+4
| | | | | | | | | | | | | | Summary: Enables users to add comment handlers to preprocessor when building preambles. Reviewers: ilya-biryukov, ioeric Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D57507 llvm-svn: 353030
* [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
* [AST] Update the comments of the various Expr::Ignore* + Related cleanupsBruno Ricci2019-02-037-89/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The description of what the various Expr::Ignore* do has drifted from the actual implementation. Inspection reveals that IgnoreParenImpCasts() is not equivalent to doing IgnoreParens() + IgnoreImpCasts() until reaching a fixed point, but IgnoreParenCasts() is equivalent to doing IgnoreParens() + IgnoreCasts() until reaching a fixed point. There is also a fair amount of duplication in the various Expr::Ignore* functions which increase the chance of further future inconsistencies. In preparation for the next patch which will factor out the implementation of the various Expr::Ignore*, do the following cleanups: Remove Stmt::IgnoreImplicit, in favor of Expr::IgnoreImplicit. IgnoreImplicit is the only function among all of the Expr::Ignore* which is available in Stmt. There are only a few users of Stmt::IgnoreImplicit. They can just use instead Expr::IgnoreImplicit like they have to do for the other Ignore*. Move Expr::IgnoreImpCasts() from Expr.h to Expr.cpp. This made no difference in the run-time with my usual benchmark (-fsyntax-only on all of Boost). While we are at it, make IgnoreParenNoopCasts take a const reference to the ASTContext for const correctness. Update the comments to match what the Expr::Ignore* are actually doing. I am not sure that listing exactly what each Expr::Ignore* do is optimal, but it certainly looks better than the current state which is in my opinion between misleading and just plain wrong. The whole patch is NFC (if you count removing Stmt::IgnoreImplicit as NFC). Differential Revision: https://reviews.llvm.org/D57266 Reviewed By: aaron.ballman llvm-svn: 353006
* [ASTDump] Add a flag indicating whether a CXXThisExpr is implicitBruno Ricci2019-02-031-0/+2
| | | | | | | | | | | 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
* [objc-gnustep] Fix encoding of ivar size for _Bool.David Chisnall2019-02-031-3/+1
| | | | llvm-svn: 352995
* [AST] Extract ASTNodeTraverser class from ASTDumperStephen Kelly2019-02-031-558/+29
| | | | | | | | | | | | | | | | | | Summary: This new traverser class allows clients to re-use the traversal logic which was previously part of ASTDumper. This means that alternative visit logic may be implemented, such as * Dump to alternative data formats such as JSON * Implement AST Matcher parent/child visitation matching AST dumps Reviewers: aaron.ballman Subscribers: jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D57472 llvm-svn: 352989
* Fix handling of usual deallocation functions in various configuratios.Eric Fiselier2019-02-031-2/+7
| | | | | | | | | | | | | 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
* [NewPM] Add support for new-PM plugins to clangPhilip Pfaffe2019-02-023-0/+21
| | | | | | | | | | | | | | | 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
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-022-13/+110
| | | | | | | | | | | | | | | | | | | 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-023-4/+50
| | | | | | | | | | | | | | | 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
* [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
* [analyzer] Hotfix for RetainCountChecker: assert was too strong.George Karpenkov2019-02-011-4/+3
| | | | | | Bridged casts can happen to non-CF objects as well. llvm-svn: 352938
* Revert "[AST][OpenMP] OpenMP Sections / Section constructs contain ↵Roman Lebedev2019-02-011-14/+0
| | | | | | | | | | | | Structured blocks" Further reviews (D57594, D57615) have revealed that this was not reviewed, and that the differential's description was not read during the review, thus rendering this commit invalid. This reverts commit r352882. llvm-svn: 352933
* [WebAssembly] Add an import_field function attributeDan Gohman2019-02-012-1/+33
| | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud