summaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-273-39/+59
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359367 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] Initialize HasMTEVitaly Buka2019-04-271-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359366 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-272-40/+29
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359361 91177308-0d34-0410-b5e6-96231b3b80d8
* [Fuchsia] Support multilib for -fsanitize=address and -fno-exceptionsPetr Hosek2019-04-274-50/+64
| | | | | | | | | | | | | | | This introduces a support for multilibs to Fuchsia driver. Unlike the existing multilibs that are used primarily for handling different architecture variants, we use multilibs to handle different variants of Clang runtime libraries: -fsanitize=address and -fno-exceptions are the two we support initially. This replaces the existing support for sanitized runtimes libraries that was only used by Fuchsia driver and it also refactors some of the logic to allow sharing between GNU and Fuchsia drivers. Differential Revision: https://reviews.llvm.org/D61040 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359360 91177308-0d34-0410-b5e6-96231b3b80d8
* [Driver] Support priority for multilibsPetr Hosek2019-04-271-4/+16
| | | | | | | | | | | When more than one multilib flag matches, try to select the best possible match based on priority. When two different multilibs with the same same priority match, we still throw an error matching the existing behavior. Differential Revision: https://reviews.llvm.org/D60990 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359359 91177308-0d34-0410-b5e6-96231b3b80d8
* [driver][macOS] Link libarclite from the default toolchain when clangAlex Lorenz2019-04-261-1/+30
| | | | | | | | | | | | | | | is running in a toolchain outside of xcode 'libarclite' usually lives in the same toolchain as 'clang'. However, the Swift open source toolchains for macOS distribute Clang without 'libarclite'. In that case, to allow the linker to find 'libarclite', we point to the 'libarclite' that should be in the XcodeDefault toolchain instead. The path to the toolchain is inferred from the SDK path if it's specified. https://bugs.swift.org/browse/SR-9972 rdar://49947573 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359353 91177308-0d34-0410-b5e6-96231b3b80d8
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-265-0/+258
| | | | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359348 91177308-0d34-0410-b5e6-96231b3b80d8
* [MinGW] Always emit local typeinfoMartin Storsjo2019-04-261-1/+1
| | | | | | | | | | | | This makes sure that code built with headers for a statically linked libc++ also works when linking to the DLL version, when the DLL hasn't been built with --export-all-symbols. This matches what GCC for MinGW does for this test case. Differential Revision: https://reviews.llvm.org/D61177 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359345 91177308-0d34-0410-b5e6-96231b3b80d8
* [HIP] Fix visibility of `__constant__` variables.Michael Liao2019-04-261-1/+2
| | | | | | | | | | | | | | | | Summary: - `__constant__` variables should not be `hidden` as the linker may turn them into `LOCAL` symbols. Reviewers: yaxunl Subscribers: jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61194 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359344 91177308-0d34-0410-b5e6-96231b3b80d8
* [MinGW] Do dllexport inline methods in template instantiationMartin Storsjo2019-04-261-2/+5
| | | | | | | | | | | | | | | | | | Normally, in MinGW mode, inline methods aren't dllexported. However, in the case of a dllimported template instantiation, the inline methods aren't instantiated locally, but referenced from the instantiation. Therefore, those methods also need to be dllexported, in the case of an instantiation. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 Differential Revision: https://reviews.llvm.org/D61176 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359343 91177308-0d34-0410-b5e6-96231b3b80d8
* [MinGW] Don't let template instantiation declarations cover nested classesMartin Storsjo2019-04-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An explicit template instantiation declaration used to let callers assume both outer and nested classes instantiations were defined in a different translation unit. If the instantiation is marked dllexport, only the outer class is exported, but the caller will try to reference the instantiation of both outer and inner classes. This makes MinGW mode match both MSVC and Windows Itanium, by having instantations only cover the outer class, and locally emitting definitions of the nested classes. Windows Itanium was changed to use this behavious in SVN r300804. This deviates from what GCC does, but should be safe (and only inflate the object file size a bit, but MSVC and Windows Itanium modes do the same), and fixes cases where inner classes aren't dllexported. This fixes missing references in combination with dllexported/imported template intantiations. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. The issue can probably be solved either by making dllexport cover all nested classes as well, or this way (matching MSVC). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 Differential Revision: https://reviews.llvm.org/D61175 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359342 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Added check for non-random access types for the dependent loopAlexey Bataev2019-04-261-51/+78
| | | | | | | | | | | counters. According to the OpenMP 5.0, For any associated loop where the b or lb expression is not loop invariant with respect to the outermost loop, the var-outer that appears in the expression may not have a random access iterator type. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359340 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter] Copy Argument Passing Restrictions setting when importing a ↵Shafik Yaghmour2019-04-261-0/+3
| | | | | | | | | | | | | | | CXXRecordDecl definition Summary: For a CXXRecordDecl the RecordDeclBits are stored in the DeclContext. Currently when we import the definition of a CXXRecordDecl via the ASTImporter we do not copy over this data. This change will add support for copying the ArgPassingRestrictions from RecordDeclBits to fix an LLDB expression parsing bug where we would set it to not pass in registers. Note, we did not copy over any other of the RecordDeclBits since we don't have tests for those. We know that copying over LoadedFieldsFromExternalStorage would be a error and that may be the case for others as well. The companion LLDB review: https://reviews.llvm.org/D61146 Differential Review: https://reviews.llvm.org/D61140 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359338 91177308-0d34-0410-b5e6-96231b3b80d8
* [BPF] do not generate predefined macro bpfYonghong Song2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | "DefineStd(Builder, "bpf", Opts)" generates the following three macros: bpf __bpf __bpf__ and the macro "bpf" is due to the fact that the target language is C which allows GNU extensions. The name "bpf" could be easily used as variable name or type field name. For example, in current linux kernel, there are four places where bpf is used as a field name. If the corresponding types are included in bpf program, the compilation error will occur. This patch removed predefined macro "bpf" as well as "__bpf" which is rarely used if used at all. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61173 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359310 91177308-0d34-0410-b5e6-96231b3b80d8
* [MinGW] Fix dllexport of explicit template instantiationMartin Storsjo2019-04-262-4/+29
| | | | | | | | | | | | | | | | | Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instantiations as dllexport in MinGW mode, if the instantiation had a previous declaration, regardless of where the attribute was placed. This makes Clang behave like GCC in this regard, and allows using the same attribute form for both MinGW compilers. This fixes PR40256. Differential Revision: https://reviews.llvm.org/D61118 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359285 91177308-0d34-0410-b5e6-96231b3b80d8
* [Analyzer] Iterator Checkers - Do an early return after handling callsAdam Balogh2019-04-261-22/+64
| | | | | | | | | | | | | This patch is more of a fix than a real improvement: in checkPostCall() we should return immediately after finding the right call and handling it. This both saves unnecessary processing and double-handling calls by mistake. Differential Revision: https://reviews.llvm.org/D61134 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359283 91177308-0d34-0410-b5e6-96231b3b80d8
* PR41607: Don't forget to substitute outer template arguments into aRichard Smith2019-04-261-5/+9
| | | | | | class-scope explicit specialization of a class template. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359266 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] RetainCount: Add a suppression for "the Matching rule".Artem Dergachev2019-04-261-14/+21
| | | | | | | | | | | | | | | | In the OSObject universe there appears to be another slightly popular contract, apart from "create" and "get", which is "matching". It optionally consumes a "table" parameter and if a table is passed, it fills in the table and returns it at +0; otherwise, it creates a new table, fills it in and returns it at +1. For now suppress false positives by doing a conservative escape on all functions that end with "Matching", which is the naming convention that seems to be followed by all such methods. Differential Revision: https://reviews.llvm.org/D61161 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359264 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] RetainCount: Allow offsets in return values.Artem Dergachev2019-04-261-2/+4
| | | | | | | | | | | | | | | | | | Because RetainCountChecker has custom "local" reasoning about escapes, it has a separate facility to deal with tracked symbols at end of analysis and check them for leaks regardless of whether they're dead or not. This facility iterates over the list of tracked symbols and reports them as leaks, but it needs to treat the return value specially. Some custom allocators tend to return the value with an offset, storing extra metadata at the beginning of the buffer. In this case the return value would be a non-base region. In order to avoid false positives, we still need to find the original symbol within the return value, otherwise it'll be unable to match it to the item in the list of tracked symbols. Differential Revision: https://reviews.llvm.org/D60991 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359263 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Fix crash when returning C++ objects from ObjC messages-to-nil.Artem Dergachev2019-04-261-1/+8
| | | | | | | | | | | the assertion is in fact incorrect: there is a cornercase in Objective-C++ in which a C++ object is not constructed with a constructor, but merely zero-initialized. Namely, this happens when an Objective-C message is sent to a nil and it is supposed to return a C++ object. Differential Revision: https://reviews.llvm.org/D60988 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359262 91177308-0d34-0410-b5e6-96231b3b80d8
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-261-30/+51
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359260 91177308-0d34-0410-b5e6-96231b3b80d8
* Add missing diagnostic for explicit instantiation declarations namingRichard Smith2019-04-261-20/+46
| | | | | | | | | | | | | | | | | internal linkage entities. Such constructs are ill-formed by [temp.explicit]p13. We make a special exception to permit an invalid construct used by libc++ in some build modes: its <valarray> header declares some functions with the internal_linkage attribute and then (meaninglessly) provides explicit instantiation declarations for them. Luckily, Clang happens to effectively ignore the explicit instantiation declaration when generating code in this case, and this change codifies that behavior. This reinstates part of r359048, reverted in r359076. (The libc++ issue triggering the rollback has been addressed.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359259 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert lib/Header: Fix Visual Studio buildsTom Stellard2019-04-261-1/+1
| | | | | | | | This reverts r359257 (git commit 00d9789509a4c573a48f60893b95314a119edd42) This broke check-clang. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359258 91177308-0d34-0410-b5e6-96231b3b80d8
* lib/Header: Fix Visual Studio buildsTom Stellard2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This is a follow up to r355253, which inadvertently broke Visual Studio builds by trying to copy files from CMAKE_CFG_INTDIR. See https://reviews.llvm.org/D58537#inline-532492 Reviewers: smeenai, vzakhari, phosek Reviewed By: smeenai Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61054 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359257 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [COFF] Statically link certain runtime library functionsReid Kleckner2019-04-251-7/+3
| | | | | | | | | This reverts r359250 (git commit 4730604bd3a361c68b92b18bf73a5daa15afe9f4) The newly added test should use -cc1 and -emit-llvm and there are other test failures that need fixing. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359251 91177308-0d34-0410-b5e6-96231b3b80d8
* [COFF] Statically link certain runtime library functionsReid Kleckner2019-04-251-3/+7
| | | | | | | | | | | | | | | | | | | Statically link certain runtime library functions for MSVC/GNU Windows environments. This is consistent with MSVC behavior. Fixes LNK4286 and LNK4217 warnings from link.exe when linking the static CRT: LINK : warning LNK4286: symbol '__std_terminate' defined in 'libvcruntime.lib(ehhelpers.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.asan_noinst_test.cc.x86_64-calls.o' LINK : warning LNK4286: symbol '__std_terminate' defined in 'libvcruntime.lib(ehhelpers.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.asan_test_main.cc.x86_64-calls.o' LINK : warning LNK4217: symbol '_CxxThrowException' defined in 'libvcruntime.lib(throw.obj)' is imported by 'ASAN_NOINST_TEST_OBJECTS.gtest-all.cc.x86_64-calls.o' in function '"int `public: static class UnitTest::GetInstance * __cdecl testing::UnitTest::GetInstance(void)'::`1'::dtor$5" (?dtor$5@?0??GetInstance@UnitTest@testing@@SAPEAV12@XZ@4HA)' Reviewers: mstorsjo, efriedma, TomTan, compnerd, smeenai, mgrang Subscribers: abdulras, theraven, smeenai, pcc, mehdi_amini, javed.absar, inglorion, kristof.beyls, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D55229 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359250 91177308-0d34-0410-b5e6-96231b3b80d8
* [CUDA] Implemented _[bi]mma* builtins.Artem Belevich2019-04-253-223/+354
| | | | | | | | | | | | | | | | These builtins provide access to the new integer and sub-integer variants of MMA (matrix multiply-accumulate) instructions provided by CUDA-10.x on sm_75 (AKA Turing) GPUs. Also added a feature for PTX 6.4. While Clang/LLVM does not generate any PTX instructions that need it, we still need to pass it through to ptxas in order to be able to compile code that uses the new 'mma' instruction as inline assembly (e.g used by NVIDIA's CUTLASS library https://github.com/NVIDIA/cutlass/blob/master/cutlass/arch/mma.h#L101) Differential Revision: https://reviews.llvm.org/D60279 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359248 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Add FIXMEs for alpha.unix.cstring.OutOfBounds false positives.Artem Dergachev2019-04-251-0/+4
| | | | | | | Caused by incorrect strlcat() modeling in r332303, cf. https://bugs.llvm.org/show_bug.cgi?id=37687#c8 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359237 91177308-0d34-0410-b5e6-96231b3b80d8
* Skip type units/type uniquing when we know we're only emitting the type once ↵David Blaikie2019-04-251-0/+5
| | | | | | | | | | | | | | | (vtable-based emission when triggered by a strong vtable, with -fno-standalone-debug) (this would regress size without a corresponding LLVM change that avoids putting other user defined types inside type units when they aren't in their own type units - instead emitting declarations inside the type unit and a definition in the primary CU) Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D61079 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359235 91177308-0d34-0410-b5e6-96231b3b80d8
* [Windows] Separate elements in -print-search-dirs with semicolonsMartin Storsjo2019-04-251-2/+2
| | | | | | | | | | | | | | Path lists on windows should always be separated by semicolons, not colons. Reuse llvm::sys::EnvPathSeparator for this purpose (as that's also a path list that is separated in the same way). Alternatively, this could just be a local ifdef _WIN32 in this function, or generalizing the existing EnvPathSeparator to e.g. a llvm::sys::path::PathListSeparator? Differential Revision: https://reviews.llvm.org/D61121 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359233 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as ↵Kristof Umann2019-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | primitive https://bugs.llvm.org/show_bug.cgi?id=41590 For the following code snippet, UninitializedObjectChecker crashed: struct MyAtomicInt { _Atomic(int) x; MyAtomicInt() {} }; void entry() { MyAtomicInt b; } The problem was that _Atomic types were not regular records, unions, dereferencable or primitive, making the checker hit the llvm_unreachable at lib/StaticAnalyzer/Checkers/UninitializedObject/UninitializedObjectChecker.cpp:347. The solution is to regard these types as primitive as well. The test case shows that with this addition, not only are we able to get rid of the crash, but we can identify x as uninitialized. Differential Revision: https://reviews.llvm.org/D61106 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359230 91177308-0d34-0410-b5e6-96231b3b80d8
* [PGO] Enable InstrProf lowering for Clang PGO instrumentation in the new ↵Rong Xu2019-04-251-10/+27
| | | | | | | | | | | | | | | pass manager Currently InstrProf lowering is not enabled for Clang PGO instrumentation in the new pass manager. The following command "-fprofile-instr-generate -fexperimental-new-pass-manager ..." is broken. This CL enables InstrProf lowering pass for Clang PGO instrumentation in the new pass manager. Differential Revision: https://reviews.llvm.org/D61138 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359215 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix bug 37903:MS ABI: handle inline static data member and inline variable ↵Jennifer Yu2019-04-251-1/+7
| | | | | | as template static data member git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359212 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP] Improved check for the linear dependency in the non-rectangularAlexey Bataev2019-04-251-5/+29
| | | | | | | | | loop nests. Added a checks that the initializer/condition expressions depend only only of the single previous loop iteration variable. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359200 91177308-0d34-0410-b5e6-96231b3b80d8
* [PowerPC][NFC]Update licence to Apache 2Jinsong Ji2019-04-251-17/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359164 91177308-0d34-0410-b5e6-96231b3b80d8
* [codeview] Fix symbol names for dynamic initializers and atexit stubsReid Kleckner2019-04-243-6/+70
| | | | | | | | | | | | | | | | Summary: Add a new variant to GlobalDecl for these so that we can detect them more easily during debug info emission and handle them appropriately. Reviewers: rsmith, rjmccall, jyu2 Subscribers: aprantl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60930 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359148 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Initial support for non-rectangular loop nest.Alexey Bataev2019-04-241-13/+87
| | | | | | | Added basic semantic analysis for the non-rectangular loop nests for OpenMP 5.0 support. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359132 91177308-0d34-0410-b5e6-96231b3b80d8
* Use llvm::stable_sortFangrui Song2019-04-2419-78/+56
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359098 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang][HeaderSuggestion] Handle the case of dotdot with an absolute pathKadir Cetinkaya2019-04-241-4/+3
| | | | | | | | | | | | | | | | | Summary: Include insertion in clangd was inserting absolute paths when the include directory was an absolute path with a double dot. This patch makes sure double dots are handled both with absolute and relative paths. Reviewers: sammccall Subscribers: ilya-biryukov, ioeric, jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60873 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359078 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix unquoted spaces in args in clang --verbose outputHans Wennborg2019-04-241-1/+1
| | | | | | | | | | | The behaviour of not quoting spaces appears to have been introduced by mistake in r190620. Patch by Brad Moody! Differential revision: https://reviews.llvm.org/D60997 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359077 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-242-83/+50
| | | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359076 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang][HeaderSearch] Make sure there are no backslashes in suggestedPathKadir Cetinkaya2019-04-241-1/+1
| | | | | | | | Reviewers: sammccall Differential Revision: https://reviews.llvm.org/D60995 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359075 91177308-0d34-0410-b5e6-96231b3b80d8
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-243-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359067 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r350917 "[Sema] If CheckPlaceholderExpr rewrites the initializerRichard Smith2019-04-243-13/+14
| | | | | | | | | | | | | | of an auto" This commit changed the initializer expression passed into initialization (stripping off an enclosing pair of parentheses or braces) and subtly changing the meaning of programs, typically by inserting bogus calls to copy constructors. See the added testcase in test/SemaCXX/cxx1y-init-captures.cpp for an example of the breakage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359066 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix interactions between __builtin_constant_p and constexpr to matchRichard Smith2019-04-242-29/+40
| | | | | | | | | | | | | | | | | | current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359059 91177308-0d34-0410-b5e6-96231b3b80d8
* Add missing diagnostic for anonymous struct/union definitions that don'tRichard Smith2019-04-241-0/+12
| | | | | | introduce any names. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359051 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve -Wuninitialized warning under ARC for block variables that areAkira Hatanaka2019-04-231-1/+2
| | | | | | | | | | | recursively captured. Under ARC, a block variable is zero-initialized when it is recursively captured by the block literal initializer. rdar://problem/11022762 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359049 91177308-0d34-0410-b5e6-96231b3b80d8
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-232-50/+83
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359048 91177308-0d34-0410-b5e6-96231b3b80d8
* Move setTargetAttributes after setGVProperties in SetFunctionAttributesScott Linder2019-04-231-5/+5
| | | | | | | | | | | AMDGPU currently relies on global properties being set before setTargetProperties is called. Existing targets like MIPS which rely on setTargetProperties do not rely on the current behavior, so this patch moves the call later in SetFunctionAttributes. Differential Revision: https://reviews.llvm.org/D60967 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359039 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Fix macro names in diagnostics within bigger macros.Artem Dergachev2019-04-231-36/+15
| | | | | | | | | If macro "CHECK_X(x)" expands to something like "if (x != NULL) ...", the "Assuming..." note no longer says "Assuming 'x' is equal to CHECK_X". Differential Revision: https://reviews.llvm.org/D59121 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@359037 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status