summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [IR] IntrinsicInst - silence static analyzer dyn_cast<> null dereference ↵Simon Pilgrim2019-09-241-2/+2
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 372733
* LoopVectorize - silence static analyzer dyn_cast<CmpInst> null dereference ↵Simon Pilgrim2019-09-241-1/+1
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<CmpInst> directly and if not assert will fire for us. llvm-svn: 372732
* [tblgen] Disable Leak detection for ASan/GCC and LSan/LLVMKamil Rytarowski2019-09-241-4/+9
| | | | | | | | | | | | | | | | Summary: Add support for sanitizing TableGen.cpp with ASan/GCC and LSan/LLVM. Reviewers: fjricci, kcc, aaron.ballman, mgorny Reviewed By: fjricci Subscribers: jakubjelinek, llvm-commits, #llvm Tags: #llvm Differential Revision: https://reviews.llvm.org/D67908 llvm-svn: 372731
* [TSAN] Add read/write range interface functions with PCJoachim Protze2019-09-243-0/+53
| | | | | | | | | | Adding annotation function variants __tsan_write_range_pc and __tsan_read_range_pc to annotate ranged access to memory while providing a program counter for the access. Differential Revision: https://reviews.llvm.org/D66885 llvm-svn: 372730
* [lldb] Use convert_to_slash in CppModuleConfigurationRaphael Isemann2019-09-241-3/+3
| | | | | | That's what we actually want to do. Might fix the Windows bot. llvm-svn: 372729
* [SimplifyCFG] FoldTwoEntryPHINode - silence static analyzer null dereference ↵Simon Pilgrim2019-09-241-0/+1
| | | | | | | | warning. NFCI. Assert that we've found the DomBlock. llvm-svn: 372728
* SimplifyCFG - silence static analyzer dyn_cast<LandingPadInst> null ↵Simon Pilgrim2019-09-241-1/+1
| | | | | | | | dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<LandingPadInst> directly and if not assert will fire for us. llvm-svn: 372727
* SimplifyCFG - silence static analyzer dyn_cast<Instruction> null dereference ↵Simon Pilgrim2019-09-241-2/+1
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<Instruction> directly and if not assert will fire for us. llvm-svn: 372726
* [clangd] Collect macros in the preamble region of the main fileHaojian Wu2019-09-249-113/+126
| | | | | | | | | | | | | | | | Summary: - store all macro references in the ParsedAST; - unify the two variants of CollectMainFileMacros; Reviewers: ilya-biryukov Subscribers: MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67496 llvm-svn: 372725
* [lldb][NFC] Use llvm::StringRef in formatters::NSStringSummaryProviderRaphael Isemann2019-09-241-11/+11
| | | | llvm-svn: 372724
* [ModuloSchedule] KernelRewriter::rewrite - silence static analyzer ↵Simon Pilgrim2019-09-241-0/+1
| | | | | | | | dyn_cast<> null dereference warning. NFCI. Assert that we've found the start of the MI schedule list. llvm-svn: 372723
* [ARM] Split large widening MVE loadsDavid Green2019-09-242-304/+118
| | | | | | | | | | | | Similar to rL372717, we can force the splitting of extends of vector loads in MVE, in order to use the better widening loads as opposed to going through expensive extends. This adds a combine to early-on detect extends of loads and split the load in two, from where normal legalisation will kick in and we get a series of widening loads. Differential Revision: https://reviews.llvm.org/D67909 llvm-svn: 372721
* lowerObjCCall - silence static analyzer dyn_cast<CallInst> null dereference ↵Simon Pilgrim2019-09-241-1/+1
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<CallInst> directly and if not assert will fire for us. llvm-svn: 372720
* [ARM] MVE sext and widen/narrow tests from larger types. NFCDavid Green2019-09-242-2/+859
| | | | llvm-svn: 372719
* [ARM] Split large truncating MVE storesDavid Green2019-09-243-109/+157
| | | | | | | | | | | | | | | | | | | | | MVE does not have a simple sign extend instruction that can move elements across lanes. We currently often end up moving each lane into and out of a GPR, in order to get elements into the correct places. When we have a store of a trunc (or a extend of a load), we can instead just split the store/load in two, using the narrowing/widening load/store instructions from each half of the vector. This does that for stores. It happens very early in a store combine, so as to easily detect the truncates. (It would be possible to do this later, but that would involve looking through a buildvector of extract elements. Not impossible but this way seemed simpler). By enabling store combines we also get a vmovdrr combine for free, helping some other tests. Differential Revision: https://reviews.llvm.org/D67828 llvm-svn: 372717
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-2462-203/+437
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* [clang-tidy][test] Add -fexceptions to bugprone-infinite-loop.testFangrui Song2019-09-241-1/+1
| | | | | | | | This fixes llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast. -fexceptions is disabled by default on XCore and PS4. llvm-svn: 372715
* [modularize] Fix compilation warning after r372681Mikael Holmen2019-09-241-0/+2
| | | | | | | | | | | | | | | | In r372681 lang_cxx_11 and lang_cxx_14 were added to LanguageIDs but they were not handled in the switch in VisitLinkageSpecDecl in Modularize.cpp so at clang 8 complained with /data/repo/master/clang-tools-extra/modularize/Modularize.cpp:583:13: error: enumeration values 'lang_cxx_11' and 'lang_cxx_14' not handled in switch [-Werror,-Wswitch] switch (D->getLanguage()) { ^ 1 error generated. With this patch we now treat lang_cxx, lang_cxx_11 and lang_cxx_14 the same way in the switch in VisitLinkageSpecDecl. llvm-svn: 372714
* gn build: Merge r372712GN Sync Bot2019-09-241-0/+1
| | | | llvm-svn: 372713
* [llvm-objcopy] Refactor ELF-specific config out to ELFCopyConfig. NFC.Seiya Nuta2019-09-247-128/+220
| | | | | | | | | | | | | | | | | | | | | Summary: This patch splits the command-line parsing into two phases: First, parse cross-platform options and leave ELF-specific options unparsed. Second, in the ELF implementation, parse ELF-specific options and construct ELFCopyConfig. Reviewers: espindola, alexshap, rupprecht, jhenderson, jakehehrlich, MaskRay Reviewed By: alexshap, jhenderson, jakehehrlich, MaskRay Subscribers: mgorny, emaste, arichardson, jakehehrlich, MaskRay, abrachet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67139 llvm-svn: 372712
* [clang-tidy] Add bugprone-infinite-loop.rst from D64736 to fix buildbotFangrui Song2019-09-241-0/+32
| | | | llvm-svn: 372711
* MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEHPavel Labath2019-09-2410-51/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The functions different in two ways: - getLLVMRegNum could return both "eh" and "other" dwarf register numbers, while getLLVMRegNumFromEH only returned the "eh" number. - getLLVMRegNum asserted if the register was not found, while the second function returned -1. The second distinction was pretty important, but it was very hard to infer that from the function name. Aditionally, for the use case of dumping dwarf expressions, we needed a function which can work with both kinds of number, but does not assert. This patch solves both of these issues by merging the two functions into one, returning an Optional<unsigned> value. While the same thing could be achieved by adding an "IsEH" argument to the (renamed) getLLVMRegNumFromEH function, it seemed better to avoid the confusion of two functions and put the choice of asserting into the hands of the caller -- if he checks the Optional value, he can safely process "untrusted" input, and if he blindly dereferences the Optional, he gets the assertion. I've updated all call sites to the new API, choosing between the two options according to the function they were calling originally, except that I've updated the usage in DWARFExpression.cpp to use the "safe" method instead, and added a test case which would have previously triggered an assertion failure when processing (incorrect?) dwarf expressions. Reviewers: dsanders, arsenm, JDevlieghere Subscribers: wdng, aprantl, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67154 llvm-svn: 372710
* [NFC] Update test after r372708David Bolvansky2019-09-241-1/+1
| | | | llvm-svn: 372709
* [Diagnostics] Do not diagnose unsigned shifts in boolean context ↵David Bolvansky2019-09-243-32/+39
| | | | | | | | (-Wint-in-bool-context) I was looking at old GCC's patch. Current "trunk" version avoids warning for unsigned case, GCC warns only for signed shifts. llvm-svn: 372708
* gn build: Merge r372706GN Sync Bot2019-09-241-0/+1
| | | | llvm-svn: 372707
* [clang-tidy] Add missing InfiniteLoopCheck.h, InfiniteLoopCheck.cpp and test ↵Fangrui Song2019-09-247-0/+533
| | | | | | from D64736 llvm-svn: 372706
* [ASTImporter] 4th attempt to fix Windows buildbot test errorsGabor Marton2019-09-241-4/+8
| | | | llvm-svn: 372705
* Revert rL372693 : [clang-tidy] New bugprone-infinite-loop check for ↵Simon Pilgrim2019-09-244-89/+0
| | | | | | | | | | | | | | | | | | detecting obvious infinite loops Finding infinite loops is well-known to be impossible (halting problem). However, it is possible to detect some obvious infinite loops, for example, if the loop condition is not changed. Detecting such loops is beneficial since the tests will hang on programs containing infinite loops so testing-time detection may be costly in large systems. Obvious cases are where the programmer forgets to increment/decrement the counter or increments/decrements the wrong variable. Differential Revision: https://reviews.llvm.org/D64736 ------- Broke some buildbots "No SOURCES given to target: obj.clangTidyBugproneModule" llvm-svn: 372704
* [Debuginfo] dbg.value points to undef value after Induction Variable ↵Alexey Lapshin2019-09-243-9/+190
| | | | | | | | | | | | | | | | | | | | | | | | | Simplification. Induction Variable Simplification pass does not update dbg.value intrinsic. Before: %add = add nuw nsw i32 %ArgIndex.06, 1 call void @llvm.dbg.value(metadata i32 %add, metadata !17, metadata !DIExpression()) After: %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 call void @llvm.dbg.value(metadata i64 undef, metadata !17, metadata !DIExpression()) There should be: %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 call void @llvm.dbg.value(metadata i64 %indvars.iv.next, metadata !17, metadata !DIExpression()) Differential Revision: https://reviews.llvm.org/D67770 llvm-svn: 372703
* [lldb][NFC] Relax completion tests for log command to make them pass on LinuxRaphael Isemann2019-09-241-15/+4
| | | | | | | | The log channels change depending on platform, so listing them breaks on some platforms. Let's just check that the 'lldb' and 'dwarf' channels are there which are independent of platform. llvm-svn: 372701
* [LLDB] Avoid warnings about redefining posix mode defines on MinGWMartin Storsjo2019-09-241-1/+11
| | | | | | | | | | | | | Since these defines were added in LLVM SVN r189364 in 2013, mingw-w64 got defines for S_I?GRP, S_IRWXG, S_I?OTH and S_IRWXO in 2015. Also change the existing defined(_MSC_VER) into ifndef S_IRUSR, for consistency. Differential Revision: https://reviews.llvm.org/D67910 llvm-svn: 372700
* [LLDB] [Windows] Add missing ifdefs to fix building for non-x86 architecturesMartin Storsjo2019-09-241-1/+14
| | | | | | | | | | While debugging on those architectures might not be supported yet, the generic code should still be buildable. This file accesses x86 specific fields in the CONTEXT struct. Differential Revision: https://reviews.llvm.org/D67911 llvm-svn: 372699
* sanitizer_common: fix freebsd build errorDmitry Vyukov2019-09-241-1/+0
| | | | | | | | Variable flags is not used. Remove it. Suggested-by: randall77 (Keith Randall) Review: https://reviews.llvm.org/D67928 llvm-svn: 372698
* [lldb] Fix log output and UtilityTests/LogChannelTest.ListRaphael Isemann2019-09-241-0/+1
| | | | | | | I refactored this code in 372691 and it seems I didn't fully replicate the original log output, so that test was failing. llvm-svn: 372696
* [LV] Forced vectorization with runtime checks and OptForSizeSjoerd Meijer2019-09-242-3/+44
| | | | | | | | | | | | | | | When vectorisation is forced with a pragma, we optimise for min size, and we need to emit runtime memory checks, then allow this code growth and don't run in an assert like we currently do. This is the result of D65197 and D66803, and was a use-case not really considered before. If this now happens, we emit an optimisation remark warning about the code-size expansion, which can be avoided by not forcing vectorisation or possibly source-code modifications. Differential Revision: https://reviews.llvm.org/D67764 llvm-svn: 372694
* [clang-tidy] New bugprone-infinite-loop check for detecting obvious infinite ↵Adam Balogh2019-09-244-0/+89
| | | | | | | | | | | | | | | | loops Finding infinite loops is well-known to be impossible (halting problem). However, it is possible to detect some obvious infinite loops, for example, if the loop condition is not changed. Detecting such loops is beneficial since the tests will hang on programs containing infinite loops so testing-time detection may be costly in large systems. Obvious cases are where the programmer forgets to increment/decrement the counter or increments/decrements the wrong variable. Differential Revision: https://reviews.llvm.org/D64736 llvm-svn: 372693
* [lldb] Remove redundant argument lists in CompletionRequestRaphael Isemann2019-09-244-20/+13
| | | | | | | | | | | We currently have two lists in the CompletionRequest that we inherited from the old API: The complete list of arguments ignoring where the user requested completion and the list of arguments that stops at the cursor. Having two lists of arguments is confusing and can lead to subtle errors, so let's remove the complete list until we actually need it. llvm-svn: 372692
* [lldb] Add completion support for log enable/disable/listRaphael Isemann2019-09-244-7/+110
| | | | | | | | | | | | | | Reviewers: #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67903 llvm-svn: 372691
* Ignore generated @import statements in the expression evaluatorRaphael Isemann2019-09-243-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject `@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling and loading unrelated C++ modules because it thinks the user has requested that it should load them. As the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths), it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS). This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements in the wrapper source code. This is done by check if the import happens in the fake source file containing our wrapper code (which implies it was generated by LLDB). This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760) Reviewers: aprantl, shafik, jingham Subscribers: lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D61565 llvm-svn: 372690
* [clang-format] NFC clang-format the clang-format unit testsPaul Hoad2019-09-241-324/+350
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It is annoying that the clang-format tests aren't themselves clang-formatted, if you use a format on save option in VS or vim this file gets massively changed then you have to `git difftool` all the other changes back out, which is risky. I know people don't like mass clang-format changes but sometimes it becomes unmanageable to not. There are no other changes here other than just the reformat. clang-format tests all pass. ``` [==========] 691 tests from 21 test cases ran. (55990 ms total) [ PASSED ] 691 tests. ``` Reviewers: klimek, owenpan, timwoj Reviewed By: owenpan Subscribers: cfe-commits Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D67888 llvm-svn: 372689
* [ASTImporter] 3rd attempt to fix Windows buildbot test errorsGabor Marton2019-09-241-4/+6
| | | | llvm-svn: 372688
* Revert "[static analyzer] Define __clang_analyzer__ macro in driver"Jan Korous2019-09-244-8/+9
| | | | | | This reverts commit fbd13570b0d5f92ef2cf6bcfe7cc2f6178500187. llvm-svn: 372687
* Revert "[lit] Add -D__clang_analyzer__ to clang_analyze_cc1"Jan Korous2019-09-241-1/+1
| | | | | | This reverts commit 4185460f758b98ea5b898c04c179704756ca8f53. llvm-svn: 372686
* Revert "[static analyzer][test] Test directly that driver sets ↵Jan Korous2019-09-241-2/+5
| | | | | | | | D__clang_analyzer__" This reverts commit c7541903d72765a38808e9973572a8d50c9d94fb. llvm-svn: 372685
* Fix int to bool errors exposed due to r372612.Rumeet Dhindsa2019-09-243-4/+4
| | | | | | | | | Differential Revision: https://reviews.llvm.org/D67937 M lib/builtins/fp_add_impl.inc M lib/builtins/fp_lib.h M lib/builtins/fp_trunc_impl.inc llvm-svn: 372684
* [static analyzer][test] Test directly that driver sets D__clang_analyzer__Jan Korous2019-09-241-5/+2
| | | | | | Follow-up to fbd13570b0d llvm-svn: 372683
* [lit] Add -D__clang_analyzer__ to clang_analyze_cc1Jan Korous2019-09-241-1/+1
| | | | | | Fixup after fbd13570b0d llvm-svn: 372682
* Support for DWARF-5 C++ language tags.Adrian Prantl2019-09-249-8/+45
| | | | | | | | | | | | This patch provides support for DW_LANG_C_plus_plus_11, DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D67613 Reapplies r372663 after adapting a failing test in the LLDB testsuite. llvm-svn: 372681
* [static analyzer] Remove --analyze-autoJan Korous2019-09-244-7/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D67934 llvm-svn: 372680
* [static analyzer] Define __clang_analyzer__ macro in driverJan Korous2019-09-244-9/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D67938 llvm-svn: 372679
OpenPOWER on IntegriCloud