summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [MemorySSA] Make the use of moveAllAfterMergeBlocks consistent.Alina Sbirlea2019-10-095-29/+113
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The rule for the moveAllAfterMergeBlocks API si for all instructions from `From` to have been moved to `To`, while keeping the CFG edges (and block terminators) unchanged. Update all the callsites for moveAllAfterMergeBlocks to follow this. Pending follow-up: since the same behavior is needed everytime, merge all callsites into one. The common denominator may be the call to `MergeBlockIntoPredecessor`. Resolves PR43569. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68659 llvm-svn: 374177
* [NFC] Reverting changes from test commit.Mitchell Balan2019-10-091-2/+0
| | | | | | llvm commit access test succeeded. llvm-svn: 374175
* [NFC] Test commit.Mitchell Balan2019-10-091-0/+2
| | | | | | Testing llvm commit access only. llvm-svn: 374174
* [scudo][standalone] Get statistics in a char bufferKostya Kortchinsky2019-10-0914-69/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Following up on D68471, this CL introduces some `getStats` APIs to gather statistics in char buffers (`ScopedString` really) instead of printing them out right away. Ultimately `printStats` will just output the buffer, but that allows us to potentially do some work on the intermediate buffer, and can be used for a `mallocz` type of functionality. This allows us to pretty much get rid of all the `Printf` calls around, but I am keeping the function in for debugging purposes. This changes the existing tests to use the new APIs when required. I will add new tests as suggested in D68471 in another CL. Reviewers: morehouse, hctim, vitalybuka, eugenis, cferris Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68653 llvm-svn: 374173
* [clang-format] Update noexcept reference qualifiers detectionKrasimir Georgiev2019-10-092-21/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r373165 fixed an issue where a templated noexcept member function with a reference qualifier would be indented more than expected: ``` // Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes // before r373165: struct f { template <class T> void bar() && noexcept {} }; // after: struct f { template <class T> void bar() && noexcept {} }; ``` The way this is done is that in the AnnotatingParser in `lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&` (the line in determineTokenType ``` Current.Type = determineStarAmpUsage(... ``` is not performed in some cases anymore, combining with a few additional related checks afterwards. The net effect of these checks results in the `&` or `&&` token to start being classified as `TT_Unknown` in cases where before `r373165` it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by `determineStarAmpUsage`. This inadvertently caused 2 classes of regressions I'm aware of: - The address-of `&` after a function assignment would be classified as `TT_Unknown`, causing spaces to surround it, disregarding style options: ``` // before r373165: void (*fun_ptr)(void) = &fun; // after: void (*fun_ptr)(void) = & fun; ``` - In cases where there is a function declaration list -- looking macro between a template line and the start of the function declaration, an `&` as part of the return type would be classified as `TT_Unknown`, causing spaces to surround it: ``` // before r373165: template <class T> DEPRECATED("lala") Type& foo(); // after: template <class T> DEPRECATED("lala") Type & foo(); ``` In these cases the problems are rooted in the skipping of the classification of a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting decisions later in the pipeline. I've looked into the goal of r373165 and noticed that replacing `noexcept` with `const` in the given example produces no extra indentation with the old code: ``` // before r373165: struct f { template <class T> int foo() & const {} }; struct f { template <class T> int foo() & noexcept {} }; ``` I investigated how clang-format annotated these two examples differently to determine the places where the processing of both diverges in the pipeline. There were two places where the processing diverges, causing the extra indent in the `noexcept` case: 1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept` is annotated as `TT_Unknown`. I've updated the `determineTokenType` function to account for this by adding a missing `tok:kw_noexcept` to the clause that marks a token as `TT_TrailingAnnotation`. 2. The `&` in the second example is wrongly identified as `TT_BinaryOperator` in `determineStarAmpUsage`. This is the reason for the extra indentation -- clang-format gets confused and thinks this is an expression. I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`. With these two updates in place, the additional parsing introduced by r373165 becomes unnecessary and all added tests pass (with updates, as now clang-format respects the style configuration for spaces around the `&` in the test examples). I've removed these additions and added regression tests for the cases above. Reviewers: AndWass, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D68695 llvm-svn: 374172
* Fix Wdocumentation unknown parameter warning. NFCI.Simon Pilgrim2019-10-091-1/+1
| | | | llvm-svn: 374171
* [llvm-exegesis] Ensure that ExecutableFunction are aligned.Clement Courbet2019-10-091-6/+10
| | | | | | | | | | | | | | Summary: Experiments show that this is the alignment we get (for ELF+Linux), but let's ensure that we have it. Reviewers: gchatelet Subscribers: tschuett, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68703 llvm-svn: 374170
* Add and adjust saturating tests. NFCDavid Green2019-10-0912-30/+1792
| | | | | | | This adds some extra testing to the existing [su][add/sub]_sat X86 and AArch64 tests and adds equivalent tests for ARM. llvm-svn: 374169
* [clangd] Make sure ReplyCallbacks are destroyed before RequestCancelersMutexKadir Cetinkaya2019-10-091-10/+13
| | | | | | | | | | | | | | | | | Summary: After rL374163, replycallbacks might have a cancellable context, which will try to access RequestCancellers on destruction. See http://45.33.8.238/mac/1245/step_7.txt for a sample failure. Reviewers: sammccall Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits, thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D68702 llvm-svn: 374168
* [clang-offload-bundler] Support `.cui` and `.d`.Michael Liao2019-10-091-0/+8
| | | | | | | | | | | | Reviewers: tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68663 llvm-svn: 374167
* [LV] Emitting SCEV checks with OptForSizeSjoerd Meijer2019-10-092-1/+39
| | | | | | | | | | | | | | | | | | | When optimising for size and SCEV runtime checks need to be emitted to check overflow behaviour, the loop vectorizer can run in this assert: LoopVectorize.cpp:2699: void llvm::InnerLoopVectorizer::emitSCEVChecks( llvm::Loop *, llvm::BasicBlock *): Assertion `!BB->getParent()->hasOptSize() && "Cannot SCEV check stride or overflow when opt We should not generate predicates while optimising for size because code will be generated for predicates such as these SCEV overflow runtime checks. This should fix PR43371. Differential Revision: https://reviews.llvm.org/D68082 llvm-svn: 374166
* [mips] Rename local variable. NFCSimon Atanasyan2019-10-091-19/+19
| | | | llvm-svn: 374165
* [mips] Split expandLoadImmReal into multiple methods. NFCSimon Atanasyan2019-10-091-154/+205
| | | | | | | | | | | The `expandLoadImmReal` handles four different and almost non-overlapping cases: loading a "single" float immediate into a GPR, loading a "single" float immediate into a FPR, and the same couple for a "double" float immediate. It's better to move each `else if` branch into separate methods. llvm-svn: 374164
* [clangd] Propagate context into reply handlersKadir Cetinkaya2019-10-091-1/+1
| | | | llvm-svn: 374163
* [llvm-exegesis] Fix r374158Clement Courbet2019-10-092-16/+16
| | | | | | | | | Some bots complain about missing 'class': LlvmState.h:70:40: error: declaration of ‘std::unique_ptr<const llvm::TargetMachine> llvm::exegesis::LLVMState::TargetMachine’ [-fpermissive] std::unique_ptr<const TargetMachine> TargetMachine; llvm-svn: 374162
* [CostModel][X86] Add tests for insertelement to non-immediate vector element ↵Simon Pilgrim2019-10-091-0/+74
| | | | | | indices llvm-svn: 374161
* [CostModel][X86] Add tests for extractelement from non-immediate vector ↵Simon Pilgrim2019-10-091-0/+74
| | | | | | element indices llvm-svn: 374160
* [ARM] Add saturating arithmetic tests for MVE. NFCDavid Green2019-10-091-0/+501
| | | | llvm-svn: 374159
* [llvm-exegesis][NFC] Remove extra `llvm::` qualifications.Clement Courbet2019-10-0937-905/+822
| | | | | | | | | | | | | | Summary: Second patch: in the lib. Reviewers: gchatelet Subscribers: nemanjai, tschuett, MaskRay, mgrang, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68692 llvm-svn: 374158
* [llvm-exegesis][NFC] Remove extra `llvm::` qualifications.Clement Courbet2019-10-0913-281/+250
| | | | | | | | | | | | Summary: First patch: in unit tests. Subscribers: nemanjai, tschuett, MaskRay, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68687 llvm-svn: 374157
* [mips] Set default float ABI to "soft" on FreeBSDSimon Atanasyan2019-10-095-9/+25
| | | | | | | | Initial patch by Kyle Evans. Fix PR43596 llvm-svn: 374154
* [DebugInfo] Enable call site debug info for ARM and AArch64Nikola Prica2019-10-093-4/+11
| | | | | | | | | | | | | | | | | ARM and AArch64 SelectionDAG support for tacking parameter forwarding register is implemented so we can allow clang invocations for those two targets. Beside that restrict debug entry value support to be emitted for LimitedDebugInfo info and FullDebugInfo. Other types of debug info do not have functions nor variables debug info. Reviewers: aprantl, probinson, dstenb, vsk Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D67004 llvm-svn: 374153
* [Sema] Emit diagnostics for uncorrected delayed typos at the end of TUIlya Biryukov2019-10-092-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of asserting all typos are corrected in the sema destructor. The sema destructor is not run in the common case of running the compiler with the -disable-free cc1 flag (which is the default in the driver). Having this assertion led to crashes in libclang and clangd, which are not reproducible when running the compiler. Asserting at the end of the TU could be an option, but finding all missing typo correction cases is hard and having worse diagnostics instead of a failing assertion is a better trade-off. For more discussion on this, see: https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html Reviewers: sammccall, rsmith Reviewed By: rsmith Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64799 llvm-svn: 374152
* Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'Ilya Biryukov2019-10-093-69/+1
| | | | | | | | | | | Also revert follow-up changes to the test. Reason: the patch breaks our internal clang-tidy integration. It's also unclear why we should use getRealPath instead of plumbing the VFS to SanitizerBlacklist, see original commit thread of cfe-commits for a discussion. llvm-svn: 374151
* [TableGen] Fix crash when using HwModes in CodeEmitterGenJames Molloy2019-10-092-1/+11
| | | | | | | | When an instruction has an encoding definition for only a subset of the available HwModes, ensure we just avoid generating an encoding rather than crash. llvm-svn: 374150
* [llvm-exegesis] Add missing std::move in rL374146.Clement Courbet2019-10-091-2/+2
| | | | | | | | | | | | This was breaking some bots: /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/include/llvm/Support/Error.h:483:5: required from ‘llvm::Expected<T>::Expected(OtherT&&, typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type*) [with OtherT = std::vector<llvm::exegesis::CodeTemplate>&; T = std::vector<llvm::exegesis::CodeTemplate>; typename std::enable_if<std::is_convertible<_Rep2, _Rep>::value>::type = void]’ /home/buildbots/ppc64le-clang-lnt-test/clang-ppc64le-lnt/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:238:20: required from here /usr/include/c++/6/bits/stl_construct.h:75:7: error: use of deleted function ‘llvm::exegesis::CodeTemplate::CodeTemplate(const llvm::exegesis::CodeTemplate&)’ { ::new(static_cast<void*>(__p)) _T1(std::forward<_Args>(__args)...); } ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm-svn: 374149
* Unify the two CRC implementationsHans Wennborg2019-10-0918-241/+155
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* [llvm-exegesis][NFC] Fix rL374146.Clement Courbet2019-10-091-1/+1
| | | | | | Remove extra semicolon: Target.cpp:187:2: warning: extra ‘;’ [-Wpedantic] llvm-svn: 374147
* [llvm-exegesis] Explore LEA addressing modes.Clement Courbet2019-10-095-17/+145
| | | | | | | | | | | | | | | | | Summary: This will help for PR32326. This shows the well-known issue with `RBP` and `R13` as base registers. Reviewers: gchatelet Subscribers: tschuett, llvm-commits, RKSimon, andreadb Tags: #llvm Differential Revision: https://reviews.llvm.org/D68646 llvm-svn: 374146
* [lldb] Don't crash when the ASTImporter produces diagnostics but instead log ↵Raphael Isemann2019-10-091-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | them. When playing with the C++ module prototype I noticed I can get LLDB to crash by making a result type that depends on __make_integer_seq (a BuiltinTemplate) which is not supported by the ASTImporter yet. This causes the ASTImporter to emit a diagnostic when copying the type to the ScratchASTContext. As deporting the result type is done after we are done parsing and the Clang's diagnostic engine asserts that it can only be used during parsing, it crashes LLDB while trying to render the diagnostic in the HandleDiagnostic method of ClangDiagnosticManagerAdapter. This patch just moves the HandleDiagnostic call to Clang behind our check that we still have a DiagnosticManager (which we remove after parsing) which prevents the assert from firing. We also shouldn't ignore such diagnostics, so I added a log statement for them. There doesn't seem to way to test this as these diagnostic only happen when we copy a node that's not supported by the ASTImporter which should never happen once we can copy everything with the ASTImporter, so every test case we add here will eventually become invalid. (Note that most of this diff is just whitespace changes as we now use an early exit instead of a huge 'if' block). llvm-svn: 374145
* Revert r374139, "[dsymutil] Fix handling of common symbols in multiple ↵Jeremy Morse2019-10-095-72/+2
| | | | | | | | | object files." The added test files ("com", "com1.o", "com2.o") are reserved names on Windows, and makes 'git checkout' fail with a filesystem error. llvm-svn: 374144
* [llvm-exegesis][NFC] Remove unecessary `using llvm::` directives.Clement Courbet2019-10-093-13/+5
| | | | | | We've been in namespace llvm for at least a year. llvm-svn: 374143
* Use lld-link instead of llvm-dlltool to create an implibRui Ueyama2019-10-091-1/+1
| | | | | | Suggested by Martin Storsjö. llvm-svn: 374142
* [lld] Don't create hints-section if Hint/Name Table is emptyRui Ueyama2019-10-093-1/+23
| | | | | | | | | | | Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports only. Patch by Stefan Schmidt. Differential revision: https://reviews.llvm.org/D68352 llvm-svn: 374140
* [dsymutil] Fix handling of common symbols in multiple object files.Jonas Devlieghere2019-10-095-2/+72
| | | | | | | | | | | | | For common symbols the linker emits only a single symbol entry in the debug map. This caused dsymutil to not relocate common symbols when linking DWARF coming form object files that did not have this entry. This patch fixes that by keeping track of common symbols in the object files and synthesizing a debug map entry for them using the address from the main binary. Differential revision: https://reviews.llvm.org/D68680 llvm-svn: 374139
* [TypeSize] Fix module builds (cassert)Kristina Brooks2019-10-091-0/+1
| | | | | | | | TypeSize.h uses `assert` statements without including the <cassert> header first which leads to failures in modular builds. llvm-svn: 374138
* Optimize operator=(const basic_string&) for tail call.Eric Fiselier2019-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Martijn Vels (mvels@google.com) Reviewed as https://reviews.llvm.org/D68276 This is a non trivial win for externally templated assignment operator. x86 without tail call (current libc++) 0000000000000000 <std::string::operator=(std::string const&)>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 53 push %rbx 5: 50 push %rax 6: 48 89 fb mov %rdi,%rbx 9: 48 39 f7 cmp %rsi,%rdi c: 74 17 je 25 <std::string::operator=(std::string const&)+0x25> e: 0f b6 56 17 movzbl 0x17(%rsi),%edx 12: 84 d2 test %dl,%dl 14: 79 07 jns 1d <std::string::operator=(std::string const&)+0x1d> 16: 48 8b 56 08 mov 0x8(%rsi),%rdx 1a: 48 8b 36 mov (%rsi),%rsi 1d: 48 89 df mov %rbx,%rdi 20: e8 00 00 00 00 callq 25 <std::string::operator=(std::string const&)+0x25> 25: 48 89 d8 mov %rbx,%rax 28: 48 83 c4 08 add $0x8,%rsp 2c: 5b pop %rbx 2d: 5d pop %rbp 2e: c3 retq After: 0000000000000000 <std::string::operator=(std::string const&)>: 0: 48 39 f7 cmp %rsi,%rdi 3: 74 14 je 19 <std::string::operator=(std::string const&)+0x19> 5: 0f b6 56 17 movzbl 0x17(%rsi),%edx 9: 84 d2 test %dl,%dl b: 79 07 jns 14 <std::string::operator=(std::string const&)+0x14> d: 48 8b 56 08 mov 0x8(%rsi),%rdx 11: 48 8b 36 mov (%rsi),%rsi 14: e9 00 00 00 00 jmpq 19 <std::string::operator=(std::string const&)+0x19> 19: 48 89 f8 mov %rdi,%rax 1c: c3 retq Benchmark (pending per https://reviews.llvm.org/D67667) ``` BM_StringAssignStr_Empty_Opaque 6.23ns ± 0% 5.19ns ± 0% -16.70% (p=0.016 n=5+4) BM_StringAssignStr_Empty_Transparent 5.86ns ± 0% 5.14ns ± 0% -12.24% (p=0.008 n=5+5) BM_StringAssignStr_Small_Opaque 8.79ns ± 1% 7.69ns ± 0% -12.53% (p=0.008 n=5+5) BM_StringAssignStr_Small_Transparent 9.44ns ± 0% 8.00ns ± 0% -15.26% (p=0.008 n=5+5) BM_StringAssignStr_Large_Opaque 25.2ns ± 0% 24.3ns ± 0% -3.50% (p=0.008 n=5+5) BM_StringAssignStr_Large_Transparent 23.6ns ± 0% 22.5ns ± 0% -4.76% (p=0.008 n=5+5) BM_StringAssignStr_Huge_Opaque 319ns ± 5% 317ns ± 5% ~ (p=0.690 n=5+5) BM_StringAssignStr_Huge_Transparent 319ns ± 5% 317ns ± 5% ~ (p=0.421 n=5+5) BM_StringAssignAsciiz_Empty_Opaque 7.41ns ± 0% 7.77ns ± 0% +4.89% (p=0.008 n=5+5) BM_StringAssignAsciiz_Empty_Transparent 7.54ns ± 3% 7.30ns ± 0% -3.24% (p=0.008 n=5+5) BM_StringAssignAsciiz_Small_Opaque 9.87ns ± 0% 10.24ns ± 1% +3.76% (p=0.008 n=5+5) BM_StringAssignAsciiz_Small_Transparent 10.4ns ± 1% 9.8ns ± 2% -5.78% (p=0.008 n=5+5) BM_StringAssignAsciiz_Large_Opaque 30.1ns ± 0% 30.1ns ± 0% ~ (p=0.167 n=5+5) BM_StringAssignAsciiz_Large_Transparent 27.1ns ± 0% 27.4ns ± 0% +0.92% (p=0.016 n=4+5) BM_StringAssignAsciiz_Huge_Opaque 383ns ± 4% 382ns ± 4% ~ (p=0.548 n=5+5) BM_StringAssignAsciiz_Huge_Transparent 375ns ± 0% 380ns ± 0% +1.37% (p=0.029 n=4+4) BM_StringAssignAsciizMix_Opaque 14.0ns ± 0% 14.0ns ± 0% ~ (p=0.881 n=5+5) BM_StringAssignAsciizMix_Transparent 13.7ns ± 1% 13.8ns ± 0% ~ (p=0.056 n=5+5) ``` llvm-svn: 374137
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-096-29/+124
| | | | | | | | | | | | whose value is not ignored. We don't warn on all the cases that are deprecated: specifically, we choose to not warn for now if there are parentheses around the assignment but its value is not actually used. This seems like a more defensible rule, particularly for cases like sizeof(v = a), where the parens are part of the operand rather than the sizeof syntax. llvm-svn: 374135
* [c++20] Implement most of P1152R4.Richard Smith2019-10-097-2/+138
| | | | | | | | | | | | | | Diagnose some now-deprecated uses of volatile types: * as function parameter types and return types * as the type of a structured binding declaration * as the type of the lvalue operand of an increment / decrement / compound assignment operator This does not implement a check for the deprecation of simple assignments whose results are used; that check requires somewhat more complexity and will be addressed separately. llvm-svn: 374133
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-085-6/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* [cxx_status] Note that Clang has supported std::source_location sinceRichard Smith2019-10-081-1/+1
| | | | | | version 9. llvm-svn: 374131
* Factor out some duplication. NFC.Richard Smith2019-10-081-5/+3
| | | | llvm-svn: 374130
* gn build: unbreak libcxx build after r374116 by restoring gen_link_script.py ↵Nico Weber2019-10-082-1/+51
| | | | | | for gn llvm-svn: 374129
* [Docs] Fixes broken sphinx build - undefined labelDeForest Richards2019-10-081-3/+0
| | | | | | Removes label ref pointing to non-existent subsystem docs page. llvm-svn: 374128
* [clang-scan-deps] Improve string/character literal skippingAlex Lorenz2019-10-082-11/+73
| | | | | | | | | | | | | | | | The existing string/character literal skipping code in the dependency directives source minimizer has two issues: - It doesn't stop the scanning when a newline is reached before the terminating character, unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line. - It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character. This commit fixes both issues. Differential Revision: https://reviews.llvm.org/D68436 llvm-svn: 374127
* [IRGen] Emit lifetime markers for temporary struct allocasFrancis Visoiu Mistrih2019-10-082-0/+111
| | | | | | | | | | | | | | When passing arguments using temporary allocas, we need to add the appropriate lifetime markers so that the stack coloring passes can re-use the stack space. This patch keeps track of all the lifetime.start calls emited before the codegened call, and adds the corresponding lifetime.end calls after the call. Differential Revision: https://reviews.llvm.org/D68611 llvm-svn: 374126
* [sanitizer] Fix crypt.cpp on Android againVitaly Buka2019-10-082-6/+3
| | | | llvm-svn: 374125
* [IA] Add tests for a few other edge casesBill Wendling2019-10-081-0/+4
| | | | | | | Test with the last eight bits within the range [7F, FF] and with lower-case hex letters. llvm-svn: 374124
* [dsymutil] Improve verbose output (NFC)Jonas Devlieghere2019-10-082-30/+55
| | | | | | | | | | | | The verbose output for finding relocations assumed that we'd always dump the DIE after (which starts with a newline) and therefore didn't include one itself. However, this isn't always true, leading to garbled output. This patch adds a newline to the verbose output and adds a line that says that the DIE is being kept (which isn't obvious otherwise). It also adds a 0x prefix to the relocations. llvm-svn: 374123
* DebugInfo: Move LLE enum handling to .def to match RLE handlingDavid Blaikie2019-10-084-16/+37
| | | | llvm-svn: 374122
OpenPOWER on IntegriCloud