FailedChanges

Changes from Git (git http://labmaster3.local/git/llvm-project.git)

Summary

  1. [LegalizeDAG] When expanding vector SRA/SRL/SHL add the new BUILD_VECTOR (details)
  2. [LegalizeDAG] Return true from ExpandNode for some nodes that don't have (details)
  3. AvoidBindCheck.cpp: Fix GCC 5.3 build errors (details)
  4. AvoidBindCheck.cpp: Fix unused variables warning (details)
  5. [lldb][NFC] Remove ThreadSafeSTLVector and ThreadSafeSTLMap and their (details)
  6. [UpdateTestChecks] Fix parsing of RUN: lines with line continuations (details)
  7. [llvm][bindings][go] Fix typo (details)
  8. [NFC] Slightly improve wording in the comments (details)
  9. [MachineVerifier]  Improve checks of target instructions operands. (details)
  10. [NFC] Tidy-ups to TimeProfiler.cpp (details)
  11. Mark some tests as xfail on AArch64 Linux (details)
  12. [LiveDebugValues] Introduce entry values of unmodified params (details)
  13. ImplicitNullChecks: Don't add a dead definition of DepMI as live-in (details)
  14. Temporarily run machine-verifier once in test/CodeGen/SPARC/fp128.ll, so (details)
  15. [asan] Remove debug locations from alloca prologue instrumentation (details)
  16. [lldb] Move register info "augmentation" from gdb-remote into ABI (details)
  17. [lldb] Remove tab from TestReturnValue.py (details)
  18. [DWARF] Add support for parsing/dumping section indices in location (details)
  19. Fixup 6d18e53: xfail TestShowLocationDwarf5.py properly (details)
Commit f92000187e149a51900c05056ed644f43603fb66 by craig.topper
[LegalizeDAG] When expanding vector SRA/SRL/SHL add the new BUILD_VECTOR
to the Results vector instead of just calling ReplaceNode
The code that processes the Results vector also calls ReplaceNode and
makes ExpandNode return true.
If we don't add it to the Results node, we end up returning false from
ExpandNode. This causes ConvertNodeToLibcall to be called next. But
ConvertNodeToLibcall doesn't do anything for shifts so they just pass
through unmodified. Except for printing a debug message.
Ultimately, I'd like to add more checks to ExpandNode and
ConvertNodeToLibcall to make sure we don't have nodes marked as Expand
that don't have any Expand or libcall handling.
The file was modifiedllvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
Commit 039664db87d255570854ade5241bf53b8ce3b5a9 by craig.topper
[LegalizeDAG] Return true from ExpandNode for some nodes that don't have
expand support.
These nodes have a FIXME that they only get here because a Custom
handler returned SDValue() instead of the original Op.
Even though we aren't expanding them, we should return true here to
prevent ConvertNodeToLibcall from also trying to process them until the
FIXME has been addressed.
I'm hoping to add checking to ConvertNodeToLibcall to make sure we don't
give it nodes it doesn't have support for.
The file was modifiedllvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
Commit 8e7f60e942ff009de742e20e10ebc09dcdecd5a2 by hans
AvoidBindCheck.cpp: Fix GCC 5.3 build errors
It was failing with:
clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp:61:29: error:
declaration of ‘clang::tidy::modernize::{anonymous}::CaptureMode
clang::tidy::modernize::{anonymous}::BindArgument::CaptureMode’
[-fpermissive]
  CaptureMode CaptureMode = CM_None;
                            ^
clang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp:38:6: error:
changes meaning of ‘CaptureMode’ from ‘enum
clang::tidy::modernize::{anonymous}::CaptureMode’ [-fpermissive]
enum CaptureMode { CM_None, CM_ByRef, CM_ByValue, CM_InitExpression };
     ^
The file was modifiedclang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
Commit b5f295ffcec2fa7402e39eb1262acbd55a7d39f5 by hans
AvoidBindCheck.cpp: Fix unused variables warning
The file was modifiedclang-tools-extra/clang-tidy/modernize/AvoidBindCheck.cpp
Commit 315600f480055f5143aaa245f25bd25221edfa91 by Raphael Isemann
[lldb][NFC] Remove ThreadSafeSTLVector and ThreadSafeSTLMap and their
use in ValueObjectSynthetic
Summary: ThreadSafeSTLVector and ThreadSafeSTLMap are not useful for
achieving any degree of thread safety in LLDB and should be removed
before they are used in more places. They are only used (unsurprisingly
incorrectly) in
`ValueObjectSynthetic::GetChildAtIndex`, so this patch replaces their
use there with a simple mutex with which we guard the related data
structures. This doesn't make ValueObjectSynthetic::GetChildAtIndex any
more thread-safe, but on the other hand it at least allows us to get rid
of the ThreadSafeSTL* data structures without changing the observable
behaviour of ValueObjectSynthetic (beside that it is now a few bytes
smaller).
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70845
The file was removedlldb/include/lldb/Core/ThreadSafeSTLMap.h
The file was modifiedlldb/include/lldb/Core/ValueObjectSyntheticFilter.h
The file was removedlldb/include/lldb/Core/ThreadSafeSTLVector.h
The file was modifiedlldb/source/Core/ValueObjectSyntheticFilter.cpp
Commit c246d6e536c7112019cba6cfc764daeb9088ef29 by Alexander.Richardson
[UpdateTestChecks] Fix parsing of RUN: lines with line continuations
I accidentally broke this in d9542db49e90457de62af3bfe395aaf4c47b68a5
due to incorrectly placed parentheses.
The file was modifiedllvm/utils/UpdateTestChecks/common.py
Commit 33f93ea23a09c89e701a12ee315decb469362ea8 by kadircet
[llvm][bindings][go] Fix typo
The file was modifiedllvm/bindings/go/llvm/dibuilder.go
Commit 9091f06994f09fceb079aa01e0fa3e1ea5c9e9f0 by kbobyrev
[NFC] Slightly improve wording in the comments
Reviewed by: hokein
Differential Revision: https://reviews.llvm.org/D70943
The file was modifiedclang-tools-extra/clangd/refactor/Rename.cpp
Commit 4fd8f11901b5bfb13a5fef597626dde31835873b by paulsson
[MachineVerifier]  Improve checks of target instructions operands.
While working with a patch for instruction selection, the splitting of a
large immediate ended up begin treated incorrectly by the backend. Where
a register operand should have been created, it instead became an
immediate. To my surprise the machine verifier failed to report this,
which at the time would have been helpful.
This patch improves the verifier so that it will report this type of
error.
This patch XFAILs CodeGen/SPARC/fp128.ll, which has been reported at
https://bugs.llvm.org/show_bug.cgi?id=44091
Review: thegameg, arsenm, fhahn https://reviews.llvm.org/D63973
The file was modifiedllvm/test/CodeGen/SPARC/fp128.ll
The file was modifiedllvm/lib/CodeGen/MachineVerifier.cpp
The file was addedllvm/test/MachineVerifier/verify-regops.mir
Commit df943a7a08102ed3d1f632e88b24a024a7c4ba81 by russell.gallop
[NFC] Tidy-ups to TimeProfiler.cpp
Remove unused include Make fields const where possible Move
initialisation to initialiser list
Differential Revision: https://reviews.llvm.org/D70904
The file was modifiedllvm/lib/Support/TimeProfiler.cpp
Commit 6d18e5366c9a0bffe45b179a830483b3f2ec9fa9 by diana.picus
Mark some tests as xfail on AArch64 Linux
I have either opened new bug reports for these tests, or added links to
existing bugs.
This should help make the lldb-aarch64-ubuntu buildbot green (there will
still be some unexpected passes that someone should look into, but those
can be handled later).
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/show_location/TestShowLocationDwarf5.py
The file was modifiedlldb/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
The file was modifiedlldb/packages/Python/lldbsuite/test/lang/cpp/trivial_abi/TestTrivialABI.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/step-avoids-no-debug/TestStepNoDebug.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/load_unload/TestLoadUnload.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/breakpoint/require_hw_breakpoints/TestRequireHWBreakpoints.py
The file was modifiedlldb/packages/Python/lldbsuite/test/commands/expression/static-initializers/TestStaticInitializers.py
Commit 4cfceb910692f9e894622da1b394324503667e46 by djordje.todorovic
[LiveDebugValues] Introduce entry values of unmodified params
The idea is to remove front-end analysis for the parameter's value
modification and leave it to the value tracking system. Front-end in
some cases marks a parameter as modified even the line of code that
modifies the parameter gets optimized, that implies that this will cover
more entry values even. In addition, extending the support for modified
parameters will be easier with this approach.
Since the goal is to recognize if a parameter’s value has changed, the
idea at very high level is: If we encounter a DBG_VALUE other than the
entry value one describing the same variable (parameter), we can assume
that the variable’s value has changed and we should not track its entry
value any more. That would be ideal scenario, but due to various LLVM
optimizations, a variable’s value could be just moved around from one
register to another
(and there will be additional DBG_VALUEs describing the same variable),
so we have to recognize such situation (otherwise, we will lose a lot of
entry values) and salvage the debug entry value.
Differential Revision: https://reviews.llvm.org/D68209
The file was addedllvm/test/DebugInfo/MIR/X86/propagate-entry-value-cross-bbs.mir
The file was modifiedllvm/lib/CodeGen/LiveDebugValues.cpp
The file was addedllvm/test/DebugInfo/MIR/X86/kill-entry-value-after-diamond-bbs.mir
The file was modifiedllvm/test/DebugInfo/MIR/ARM/dbgcall-site-propagated-value.mir
The file was addedllvm/test/DebugInfo/MIR/X86/entry-values-diamond-bbs.mir
The file was addedllvm/test/DebugInfo/MIR/X86/entry-value-of-modified-param.mir
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/TestBasicEntryValuesX86_64.py
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/main.cpp
Commit f8c0cfc24eab0f23e3ebc65b10ee4276b1f15eeb by paulsson
ImplicitNullChecks: Don't add a dead definition of DepMI as live-in
This is one of the fixes needed to reapply D68267 which improves
verification of live-in lists.
Review: craig.topper https://reviews.llvm.org/D70434
The file was modifiedllvm/lib/CodeGen/ImplicitNullChecks.cpp
The file was modifiedllvm/test/CodeGen/X86/implicit-null-checks.mir
Commit 7b63e27cc0a940a67db84b8b8485dd8b81a2beeb by paulsson
Temporarily run machine-verifier once in test/CodeGen/SPARC/fp128.ll, so
that it XFAIL:s also without expensive checks.
See https://reviews.llvm.org/D63973
The file was modifiedllvm/test/CodeGen/SPARC/fp128.ll
Commit 09667bc1920463107684a566c3f2c3cef9b156e7 by aclopte
[asan] Remove debug locations from alloca prologue instrumentation
Summary: This fixes https://llvm.org/PR26673
"Wrong debugging information with -fsanitize=address" where asan
instrumentation causes the prologue end to be computed incorrectly:
findPrologueEndLoc, looks for the first instruction with a debug
location to determine the prologue end.  Since the asan instrumentation
instructions had debug locations, that prologue end was at some
instruction, where the stack frame is still being set up.
There seems to be no good reason for extra debug locations for the asan
instrumentations that set up the frame; they don't have a natural source
location.  In the debugger they are simply located at the start of the
function.
For certain other instrumentations like
-fsanitize-coverage=trace-pc-guard the same problem persists - that
might be more work to fix, since it looks like they rely on locations of
the tracee functions.
This partly reverts aaf4bb239487e0a3b20a8eaf94fc641235ba2c29
"[asan] Set debug location in ASan function prologue" whose motivation
was to give debug location info to the coverage callback. Its test only
ensures that the call to @__sanitizer_cov_trace_pc_guard is given the
correct source location; as the debug location is still set in
ModuleSanitizerCoverage::InjectCoverageAtBlock, the test does not break.
So -fsanitize-coverage is hopefully unaffected - I don't think it should
rely on the debug locations of asan-generated allocas.
Related revision: 3c6c14d14b40adfb581940859ede1ac7d8ceae7a
"ASAN: Provide reliable debug info for local variables at -O0."
Below is how the X86 assembly version of the added test case changes. We
get rid of some .loc lines and put prologue_end where the user code
starts.
```diff
--- 2.master.s 2019-12-02 12:32:38.982959053 +0100
+++ 2.patch.s 2019-12-02 12:32:41.106246674 +0100
@@ -45,8 +45,6 @@
.cfi_offset %rbx, -24
xorl %eax, %eax
movl %eax, %ecx
- .Ltmp2:
- .loc 1 3 0 prologue_end      # 2.c:3:0
cmpl $0, __asan_option_detect_stack_use_after_return
movl %edi, 92(%rbx)          # 4-byte Spill
movq %rsi, 80(%rbx)          # 8-byte Spill
@@ -57,9 +55,7 @@
callq __asan_stack_malloc_0
movq %rax, 72(%rbx)          # 8-byte Spill
.LBB1_2:
- .loc 1 0 0 is_stmt 0         # 2.c:0:0
movq 72(%rbx), %rax          # 8-byte Reload
- .loc 1 3 0                   # 2.c:3:0
cmpq $0, %rax
movq %rax, %rcx
movq %rax, 64(%rbx)          # 8-byte Spill
@@ -72,9 +68,7 @@
movq %rax, %rsp
movq %rax, 56(%rbx)          # 8-byte Spill
.LBB1_4:
- .loc 1 0 0                   # 2.c:0:0
movq 56(%rbx), %rax          # 8-byte Reload
- .loc 1 3 0                   # 2.c:3:0
movq %rax, 120(%rbx)
movq %rax, %rcx
addq $32, %rcx
@@ -99,7 +93,6 @@
movb %r8b, 31(%rbx)          # 1-byte Spill
je .LBB1_7
# %bb.5:
- .loc 1 0 0                   # 2.c:0:0
movq 40(%rbx), %rax          # 8-byte Reload
andq $7, %rax
addq $3, %rax
@@ -118,7 +111,8 @@
movl %ecx, (%rax)
movq 80(%rbx), %rdx          # 8-byte Reload
movq %rdx, 128(%rbx)
- .loc 1 4 3 is_stmt 1         # 2.c:4:3
+.Ltmp2:
+ .loc 1 4 3 prologue_end      # 2.c:4:3
movq %rax, %rdi
callq f
movq 48(%rbx), %rax          # 8-byte Reload
```
Reviewers: eugenis, aprantl
Reviewed By: eugenis
Subscribers: ormris, aprantl, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70894
The file was addedllvm/test/Instrumentation/AddressSanitizer/debug-info-alloca.ll
The file was modifiedllvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll
The file was modifiedllvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
Commit 2b8db387f2a616f39a077ede18c6366f2ea9f203 by pavel
[lldb] Move register info "augmentation" from gdb-remote into ABI
Summary: Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now, the
"filling in" code is in the ABI plugin itself, and the gdb-remote code
just invokes that.
The motivation for this is two-fold: a) the "augmentation" logic is
useful outside of process gdb-remote. For
instance, it would allow us to avoid repeating the register number
definitions in minidump code. b) It gives more implementation freedom
to the ABI classes. Now that
these "register infos" are essentially implementation details, classes
can use other methods to obtain dwarf/eh_frame register numbers -- for
instance they can consult llvm MC layer.
Since the augmentation code was not currently tested anywhere, I took
the opportunity to create a simple test for it.
Reviewers: jasonmolenda, clayborg, tatyana-krasnukha
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70906
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py
The file was modifiedlldb/source/Target/ABI.cpp
The file was modifiedlldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
The file was modifiedlldb/include/lldb/Target/ABI.h
The file was addedlldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/basic_eh_frame.yaml
Commit 46d0ec3a803021281c8d868b1487d2d5cd06f274 by Raphael Isemann
[lldb] Remove tab from TestReturnValue.py
Mixing tabs and spaces makes Python exit with this error:
  File
"llvm/lldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py",
line 23
   return (self.getArchitecture() == "aarch64" and self.getPlatform() ==
"linux")
                                                                       
       ^ TabError: inconsistent use of tabs and spaces in indentation
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
Commit 1fbe8a82e1ea0168ee10079a18140135222d1d2c by pavel
[DWARF] Add support for parsing/dumping section indices in location
lists
Summary: This does exactly what it says on the box. The only small
gotcha is the section index computation for offset_pair entries, which
can use either the base address section, or the section from the
offset_pair entry. This is to support both the cases where the base
address is relocated
(points to the base of the CU, typically), and the case where the base
address is a constant (typically zero) and relocations are on the
offsets themselves.
Reviewers: dblaikie, JDevlieghere, aprantl, SouraVX
Subscribers: hiraditya, llvm-commits, probinson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70540
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
The file was modifiedllvm/test/DebugInfo/X86/dwarfdump-debug-loc-simple.test
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFDie.cpp
The file was modifiedllvm/test/tools/llvm-dwarfdump/X86/debug_loclists.s
The file was modifiedllvm/include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h
The file was modifiedllvm/lib/DebugInfo/DWARF/DWARFContext.cpp
Commit 057626b4393836e11712bd694afda121d8309973 by diana.picus
Fixup 6d18e53: xfail TestShowLocationDwarf5.py properly
Forgot to squash this...
The file was modifiedlldb/packages/Python/lldbsuite/test/functionalities/show_location/TestShowLocationDwarf5.py