summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* [Sema] Fix a crash in access checking for deduction guidesIlya Biryukov2019-02-121-1/+5
| | | | | | | | | | | | | | | | Summary: See the added test for a repro. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58111 llvm-svn: 353840
* Renaming yet another diagnostic to not conflict; NFC.Aaron Ballman2019-02-121-1/+2
| | | | llvm-svn: 353839
* Renaming this diagnostic to not conflict with another; NFC.Aaron Ballman2019-02-121-1/+1
| | | | | | Amends r353837 which renamed the diagnostics to conflict. llvm-svn: 353838
* Fixing a typo; NFC.Aaron Ballman2019-02-121-3/+3
| | | | llvm-svn: 353837
* [X86] Use the new unaligned vector typedefs for the loadu/storeu intrinsics ↵Craig Topper2019-02-122-8/+8
| | | | | | | | pointer arguments. This matches what gcc does and what was suggested by rnk in PR20670. llvm-svn: 353802
* Add a new attribute, fortify_stdlibErik Pilkington2019-02-114-0/+142
| | | | | | | | | | | | | | | | | | | | | | 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
* [Sema] Mark GNU compound literal array init as an rvalue.Eli Friedman2019-02-111-7/+33
| | | | | | | | | | | | | | | | | | | | | | Basically the same issue as string init, except it didn't really have any visible consequences before I removed the implicit lvalue-to-rvalue conversion from CodeGen. While I'm here, a couple minor drive-by cleanups: IgnoreParens never returns a ConstantExpr, and there was a potential crash with string init involving a ChooseExpr. The analyzer test change maybe indicates we could simplify the analyzer code a little with this fix? Apparently a hack was added to support lvalues in initializers in r315750, but I'm not really familiar with the relevant code. Fixes regression reported in the kernel build at https://bugs.llvm.org/show_bug.cgi?id=40430#c6 . Differential Revision: https://reviews.llvm.org/D58069 llvm-svn: 353762
* [WebAssembly] Make thread-related options consistentHeejin Ahn2019-02-114-9/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There have been three options related to threads and users had to set all three of them separately to get the correct compilation results. This makes sure the relationship between the options makes sense and sets necessary options for users if only part of the necessary options are specified. This does: - Remove `-matomics`; this option alone does not enable anything, so removed it to not confuse users. - `-mthread-model posix` sets `-target-feature +atomics` - `-pthread` sets both `-target-feature +atomics` and `-mthread-model posix` Also errors out when explicitly given options don't match, such as `-pthread` is given with `-mthread-model single`. Reviewers: dschuff, sbc100, tlively, sunfish Subscribers: jgravelle-google, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57874 llvm-svn: 353761
* [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
* [COFF, ARM64] Remove definitions for _byteswap library functionsTom Tan2019-02-111-9/+3
| | | | | | | | | | | | | _byteswap_* functions are are implemented in below file as normal function from libucrt.lib and declared in stdlib.h. Define them in intrin.h triggers lld error "conflicting comdat type" and "duplicate symbols" which was just added to LLD (https://reviews.llvm.org/D57324). C:\Program Files (x86)\Windows Kits\10\Source\10.0.17763.0\ucrt\stdlib\byteswap.cpp Differential Revision: https://reviews.llvm.org/D57915 llvm-svn: 353740
* Make some helper functions static. NFC.Benjamin Kramer2019-02-112-5/+4
| | | | llvm-svn: 353705
* [analyzer] New checker for detecting usages of unsafe I/O functionsKristof Umann2019-02-111-3/+95
| | | | | | | | | | | | | | | | There are certain unsafe or deprecated (since C11) buffer handling functions which should be avoided in safety critical code. They could cause buffer overflows. A new checker, 'security.insecureAPI.DeprecatedOrUnsafeBufferHandling' warns for every occurrence of such functions (unsafe or deprecated printf, scanf family, and other buffer handling functions, which now have a secure variant). Patch by Dániel Kolozsvári! Differential Revision: https://reviews.llvm.org/D35068 llvm-svn: 353698
* [clang][Index] Add a knob to index function parameters in declarationsKadir Cetinkaya2019-02-113-4/+10
| | | | | | | | | | | | | | | | | Summary: Parameters in declarations are useful for clangd, so that we can provide symbol information for them as well. It also helps clangd to be consistent whether a function's definition is accessible or not. Reviewers: hokein, akyrtzi Subscribers: ilya-biryukov, ioeric, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57949 llvm-svn: 353695
* long double is double on OpenBSD/NetBSD/PPC.Brad Smith2019-02-111-1/+7
| | | | | | Patch by George Koehler. llvm-svn: 353656
* Use llvm::is_contained. NFCFangrui Song2019-02-107-11/+9
| | | | llvm-svn: 353635
* [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
* Fix buildbot failure from r353569.Eli Friedman2019-02-091-1/+8
| | | | | | | I assumed lvalue-to-rvalue conversions of array type would never happen, but apparently clang-tidy tries in some cases. llvm-svn: 353598
* [analyzer] Add a comment that FunctionCodeRegions may also need canonicalizationArtem Dergachev2019-02-091-0/+1
| | | | llvm-svn: 353592
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-094-21/+852
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* [AMDGPU] Split dot-insts featureStanislav Mekhanoshin2019-02-091-1/+2
| | | | | | 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-9/+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-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-083-54/+26
| | | | | | | | | | | | | | | | | | | | | | | 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-082-0/+91
| | | | | | Differential Revision: https://reviews.llvm.org/D57261 llvm-svn: 353566
* Pass the base element type of an array type to the visit method insteadAkira Hatanaka2019-02-081-1/+1
| | | | | | | | | | | of the array type itself. This fixes a bug found by inspection that was introduced in r353459. I don't have a test case for this since we don't yet have types that would make the containing C struct non-trivial to copy/move but wouldn't make it non-trivial to default-initialize or destruct. llvm-svn: 353556
* [X86] Add explicit alignment to __m128/__m128i/__m128d/etc. to allow ↵Craig Topper2019-02-088-51/+64
| | | | | | | | | | | | | | | | | | | | | | | 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-085-13/+67
| | | | | | | | | | 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-085-67/+13
| | | | | | | 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-085-13/+67
| | | | | | | | | 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
* [Format/ObjC] Fix [foo bar]->baz formatting as lambda arrowBen Hamilton2019-02-082-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `UnwrappedLineParser` thinks an arrow token after an ObjC method expression is a C++ lambda arrow, so it formats: ``` [foo bar]->baz ``` as: ``` [foo bar] -> baz ``` Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't know if the arrow token is after an ObjC method expression or not. This diff makes `TokenAnnotator` remove the TT_LambdaArrow on the arrow token if it follows an ObjC method expression. Test Plan: New test added. Ran test with: % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests Confirmed test failed before diff and passed after diff. Reviewers: krasimir, djasper, sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57923 llvm-svn: 353531
* [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
* [AST] Fix structural inequivalence of operatorsGabor Marton2019-02-081-0/+6
| | | | | | | | | | | | | | Summary: Operators kind was not checked, so we reported e.g. op- to be equal with op+ Reviewers: shafik, a_sidorin, aaron.ballman Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57902 llvm-svn: 353504
* 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-082-6/+3
| | | | | | | | | | 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
* 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-072-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [SEMA]Generalize deferred diagnostic interface, NFC.Alexey Bataev2019-02-072-194/+197
| | | | | | | | | | | | | | | | | Summary: Deferred diagnostic interface is going to be used for OpenMP device compilation. Generalized previously existed deferred diagnostic interface for CUDA to be used with OpenMP and, possibly, other models. Reviewers: rjmccall, tra Subscribers: caomhin, cfe-commits, kkwli0 Tags: #clang Differential Revision: https://reviews.llvm.org/D57908 llvm-svn: 353456
* [OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0Anastasia Stulova2019-02-073-12/+11
| | | | | | | | | | 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-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
OpenPOWER on IntegriCloud