[Lldb-commits] [lldb] [lldb] Remove dead code block (NFC) (PR #94775)

fmayer wrote: Random drive-by: > The check that max_bit_pos == sign_bit_pos conflicts with the check that > sign_bit_pos < max_bit_pos in the block surrounding it. Should we add an `assert` to this function then? https://github.com/llvm/llvm-project/pull/94775

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

@@ -745,26 +745,25 @@ Status Scalar::SetValueFromData(const DataExtractor &data, bool Scalar::SignExtend(uint32_t sign_bit_pos) { const uint32_t max_bit_pos = GetByteSize() * 8; + assert(sign_bit_pos < max_bit_pos); - if (sign_bit_pos < max_bit_pos) { -switch (m_type

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/95678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/95678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB] Add an assert to verify sign_bit_pos is within the valid range (NFC) (PR #95678)

https://github.com/fmayer approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/95678 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [compiler-rt] [mlir] [llvm] [sanitizer] Pre-commit disabled test for fork (PR #75257)

https://github.com/fmayer edited https://github.com/llvm/llvm-project/pull/75257 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [mlir] [llvm] [compiler-rt] [lldb] [sanitizer] Pre-commit disabled test for fork (PR #75257)

https://github.com/fmayer approved this pull request. https://github.com/llvm/llvm-project/pull/75257 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] [compiler-rt] [mlir] [sanitizer] Pre-commit disabled test for fork (PR #75257)

fmayer wrote: would appreciate a short comment that explains what this test does in an abstract sense, like "sets up memory like so and so and verifies that this and this doesn't happen" https://github.com/llvm/llvm-project/pull/75257

[Lldb-commits] [compiler-rt] [mlir] [llvm] [lldb] [sanitizer] Pre-commit disabled test for fork (PR #75257)

@@ -18,10 +18,10 @@ static const size_t kBufferSize = 1 << 20; -static void *background(void *arg) { return nullptr; } - pthread_barrier_t bar; +// Without appropriate workarounds this code can cause the forked process to +// start with locked internal mutexes. ---

[Lldb-commits] [llvm] [lldb] [mlir] [libc] [compiler-rt] [flang] [clang] [openmp] [hwasan] Respect strip_path_prefix printing locals (PR #76132)

https://github.com/fmayer approved this pull request. Lgtm thanks https://github.com/llvm/llvm-project/pull/76132 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [llvm] [libcxx] [lldb] [flang] [openmp] [mlir] [libc] [compiler-rt] [hwasan] Classify stack overflow, and use after scope (PR #76133)

@@ -221,29 +221,55 @@ static void PrintStackAllocations(const StackAllocationsRingBuffer *sa, for (LocalInfo &local : frame.locals) { if (!local.has_frame_offset || !local.has_size || !local.has_tag_offset) continue; +if (!(local.name && intern

[Lldb-commits] [llvm] [openmp] [libc] [compiler-rt] [lldb] [mlir] [flang] [libcxx] [clang] [hwasan] Classify stack overflow, and use after scope (PR #76133)

@@ -221,29 +221,55 @@ static void PrintStackAllocations(const StackAllocationsRingBuffer *sa, for (LocalInfo &local : frame.locals) { if (!local.has_frame_offset || !local.has_size || !local.has_tag_offset) continue; +if (!(local.name && intern

[Lldb-commits] [llvm] [openmp] [libc] [compiler-rt] [lldb] [mlir] [flang] [libcxx] [clang] [hwasan] Classify stack overflow, and use after scope (PR #76133)

https://github.com/fmayer commented: Remove this comment? Line 780 ``` // TODO(fmayer): figure out how to distinguish use-after-return and // stack-buffer-overflow. ``` https://github.com/llvm/llvm-project/pull/76133 ___ lldb-commits mailing

[Lldb-commits] [libc] [clang] [openmp] [flang] [libcxx] [llvm] [compiler-rt] [lldb] [mlir] [hwasan] Classify stack overflow, and use after scope (PR #76133)

https://github.com/fmayer approved this pull request. https://github.com/llvm/llvm-project/pull/76133 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (PR #84219)

fmayer wrote: I think this broke the build completely? ``` /usr/local/google/home/fmayer/large/llvm-project/lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc64.cpp:771:14: error: no viable conversion from 'llvm::Expected' (aka 'Expected') to 'uint32_t' (aka 'unsigned int') uint32_t n = m_type.Ge

[Lldb-commits] [lldb] 300a39b - Revert "Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)"

Author: Florian Mayer Date: 2024-03-08T12:14:22-08:00 New Revision: 300a39bdad4593fdc2618eb28f6e838df735619a URL: https://github.com/llvm/llvm-project/commit/300a39bdad4593fdc2618eb28f6e838df735619a DIFF: https://github.com/llvm/llvm-project/commit/300a39bdad4593fdc2618eb28f6e838df735619a.diff

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

fmayer wrote: I don't have a strong opinion, but fundamentally I would prefer if the source control system stored exactly the files I have in my checkout, not mess with them in any way. I understand there are practical concerns, but a linter for unexpected CRLF would maybe be an option? https

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

fmayer wrote: > That wish is fine until you start working with others. Do we actually have that little faith in developers that we think they will check in a 50k line diff? https://github.com/llvm/llvm-project/pull/86318 ___ lldb-commits mailing list

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

fmayer wrote: > . The point of this patch is not to lambast developers or interfere with > their local setups; it's to get the line-ending issues out of the way for > good so they can focus on what they do best. Fair enough. I don't think it will fully make them go away for good, as you menti

[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)

fmayer wrote: LGTM, verified the two strings are the same ``` >>> r"^(.*) \(in (.*)\) \((.*:\d*)\)$" == "^(.*) \(in (.*)\) \((.*:\d*)\)$" True >>> "^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:in *.+)? *\((.*)\+(0x[0-9a-f]+)\)" == >>> r"^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:

[Lldb-commits] [libcxx] [llvm] [lld] [flang] [clang] [lldb] [libc] [libcxxabi] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

https://github.com/fmayer approved this pull request. https://github.com/llvm/llvm-project/pull/79924 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits