1. Dec 23, 2021
  2. Dec 22, 2021
    • Nikita Popov's avatar
      [JSONNodeDumper] Regenerate test checks (NFC) · da007a33
      Nikita Popov authored
      gen_ast_dump_json_test.py adds these lines of whitespace. Precommit
      it to avoid spurious diffs in future changes.
      da007a33
    • Ivan Gerasimov's avatar
      [clang-tidy] abseil-string-find-startswith: detect `s.rfind(z, 0) == 0` · fd8fc5e8
      Ivan Gerasimov authored
      Suggest converting `std::string::rfind()` calls to `absl::StartsWith()`
      where possible.
      fd8fc5e8
    • Arthur O'Dwyer's avatar
      [libc++] [ranges] Remove the static_assert from ranges::begin and ranges::end. · 8ad364ad
      Arthur O'Dwyer authored
      As discussed with ldionne. The problem with this static_assert
      is that it makes ranges::begin a pitfall for anyone ever to use
      inside a constraint or decltype. Many Ranges things, such as ranges::size,
      are specified as "Does X if X is well-formed, or else Y if Y is well-formed,
      or else `ranges::end(t) - ranges::begin(t)` if that is well-formed, or else..."
      And if there's a static_assert hidden inside `ranges::begin(t)`, then you get
      a hard error as soon as you ask the question -- even if the answer would have
      been "no, that's not well-formed"!
      
      Constraining on `requires { t + 0; }` or `requires { t + N; }` is verboten
      because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 . For ranges::begin,
      we can just decay to a pointer even in the incomplete-type case. For ranges::end,
      we can safely constrain on `sizeof(*t)`. Yes, this means that an array of incomplete
      type has a `ranges::begin` but no `ranges::end`... just like an unbounded array of
      complete type. This is a valid manifestation of IFNDR.
      
      All of the new libcxx/test/std/ cases are mandatory behavior, as far as I'm aware.
      Tests for the IFNDR cases in ranges::begin and ranges::end remain in `libcxx/test/libcxx/`.
      The similar tests for ranges::empty and ranges::data were simply wrong, AFAIK.
      
      Differential Revision: https://reviews.llvm.org/D115838
      8ad364ad
    • RamNalamothu's avatar
      [AMDGPU] Move call clobbered return address registers s[30:31] to callee saved range · 9075009d
      RamNalamothu authored
      Currently the return address ABI registers s[30:31], which fall in the call
      clobbered register range, are added as a live-in on the function entry to
      preserve its value when we have calls so that it gets saved and restored
      around the calls.
      
      But the DWARF unwind information (CFI) needs to track where the return address
      resides in a frame and the above approach makes it difficult to track the
      return address when the CFI information is emitted during the frame lowering,
      due to the involvment of understanding the control flow.
      
      This patch moves the return address ABI registers s[30:31] into callee saved
      registers range and stops adding live-in for return address registers, so that
      the CFI machinery will know where the return address resides when CSR
      save/restore happen during the frame lowering.
      
      And doing the above poses an issue that now the return instruction uses undefined
      register `sgpr30_sgpr31`. This is resolved by hiding the return address register
      use by the return instruction through the `SI_RETURN` pseudo instruction, which
      doesn't take any input operands, until the `SI_RETURN` pseudo gets lowered to the
      `S_SETPC_B64_return` during the `expandPostRAPseudo()`.
      
      As an added benefit, this patch simplifies overall return instruction handling.
      
      Note: The AMDGPU CFI changes are there only in the downstream code and another
      version of this patch will be posted for review for the downstream code.
      
      Reviewed By: arsenm
      
      Differential Revision: https://reviews.llvm.org/D114652
      9075009d
    • Michał Górny's avatar
      [lldb] [Process/FreeBSDKernel] Introduce libkvm support · fb785877
      Michał Górny authored
      Introduce initial support for using libkvm on FreeBSD.  The library
      can be used as an alternate implementation for processing kernel
      coredumps but it can also be used to access live kernel memory through
      specifying "/dev/mem" as the core file, i.e.:
      
          lldb --core /dev/mem /boot/kernel/kernel
      
      Differential Revision: https://reviews.llvm.org/D116005
      fb785877
    • Alok Kumar Sharma's avatar
      [clang][OpenMP][DebugInfo] Debug support for variables in shared clause of OpenMP task construct · 5eb27188
      Alok Kumar Sharma authored
      Currently variables appearing inside shared clause of OpenMP task construct
      are not visible inside lldb debugger.
      
      After the current patch, lldb is able to show the variable
      
      ```
      * thread #1, name = 'a.out', stop reason = breakpoint 1.1
          frame #0: 0x0000000000400934 a.out`.omp_task_entry. [inlined] .omp_outlined.(.global_tid.=0, .part_id.=0x000000000071f0d0, .privates.=0x000000000071f0e8, .copy_fn.=(a.out`.omp_task_privates_map. at testshared.cxx:8), .task_t.=0x000000000071f0c0, __context=0x000000000071f0f0) at testshared.cxx:10:34
         7      else {
         8    #pragma omp task shared(svar) firstprivate(n)
         9        {
      -> 10         printf("Task svar = %d\n", svar);
         11         printf("Task n = %d\n", n);
         12         svar = fib(n - 1);
         13       }
      (lldb) p svar
      (int) $0 = 9
      ```
      
      Reviewed By: djtodoro
      
      Differential Revision: https://reviews.llvm.org/D115510
      5eb27188
    • Nikita Popov's avatar
      [msan] Break optimization in memccpy tests · a9bb97e8
      Nikita Popov authored
      After D116148 the memccpy gets optimized away and the expected
      uninitialized memory access does not occur.
      
      Make sure the call does not get optimized away.
      a9bb97e8