Repository navigation
[libc][bazel] Update bazel overlay for ceilf128 emulated float128 changes - #2
Merged
Merged
Conversation
…nges This updates the Bazel overlay following commit e5174fe: - Remove `:llvm_libc_types_float128` from `__support_math_ceilf128` deps as `include/llvm-libc-types/float128.h` is no longer included. - Add `:__support_cpp_bit` to `ceilf128` additional_deps for `bit_cast`. - Add `ceilf128` math MPFR test target in `libc/test/src/math/BUILD.bazel`. TAG=agy CONV=5c2e315a-19b2-48ec-9cf9-98bfadbae600
DeanSturtevant1
pushed a commit
that referenced
this pull request
Sep 13, 2026
…m#205764 (llvm#221843) New LifetimeSafetyOpts fields were added in llvm#221610 but they are not initialized in clang/unittests/Analysis/LifetimeSafetyTest.cpp, leading to use-of-uninitialized-memory (https://lab.llvm.org/buildbot/#/builders/164/builds/25165): ``` WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x555571559cbc in clang::lifetimes::internal::(anonymous namespace)::LifetimeChecker::LifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:108:9 #1 0x5555715453cd in clang::lifetimes::internal::runLifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:575:19 #2 0x555571524c1e in clang::lifetimes::internal::LifetimeSafetyAnalysis::run() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:98:3 llvm#3 0x55555c3da25b in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:71:15 ... Uninitialized value was stored to memory at #0 0x55555bcd06c7 in __msan_memcpy /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1760:3 #1 0x5555715238ed in clang::lifetimes::internal::LifetimeSafetyAnalysis::LifetimeSafetyAnalysis(clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:54:39 #2 0x55555c3da1b9 in make_unique<clang::lifetimes::internal::LifetimeSafetyAnalysis, clang::AnalysisDeclContext &, std::nullptr_t, clang::lifetimes::LifetimeSafetyOpts &, 0> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__memory/unique_ptr.h:713:30 llvm#3 0x55555c3da1b9 in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:70:9 ``` This patch fixes the issue by initializing the fields in the test to true, which maintains the behavior prior to the new fields being added. Additionally, this patch does a similar drive-by fix to the SuggestAnnotations field (added in llvm#205764). Although there has been no MSan report, that's likely either an MSan false negative or insufficient test coverage.
DeanSturtevant1
pushed a commit
that referenced
this pull request
Sep 13, 2026
`target create` never returns for a little-endian 32-bit MIPS ELF file, on any host whose platform advertises `armv7m`/`armv7em` compatibility. On Darwin that is every platform, since `PlatformDarwin::GetCompatibleArchs()` lists both for every arm64/arm64e host and falls through to that same list for any other host core. It is found by `lldb-target-fuzzer`. Reproduce with a 52-byte ELF32 header (`ELFCLASS32`, `ELFDATA2LSB`, `e_machine = EM_MIPS`, `e_flags = EF_MIPS_ARCH_32`, everything else zero), saved as `mips32el.elf`: ``` (lldb) target create mips32el.elf ``` This never returns. Attaching a debugger to the hung process shows the same three frames looping forever, with the call stack never growing: ``` frame #1: cores_match(core1=eCore_arm_armv7m, core2=eCore_mips32el, try_inverse=false, ...) at ArchSpec.cpp:1575 [inlined] frame #2: ArchSpec::IsMatch(rhs=..., match=CompatibleMatch) at ArchSpec.cpp:1449 frame llvm#3: Platform::IsCompatibleArchitecture(...) at Platform.cpp:1193 ``` `cores_match()` checks `core1` against `core2`. When nothing matches and the caller did not ask for an exact match, it sets `try_inverse` and retries once with the two cores swapped. It retries because the rule tables are not symmetric: a core lists only what it accepts, not everything that accepts it. Every case that reaches this fallback must leave `try_inverse` false on the way out, so the swap happens at most once. Three cases, `eCore_arm_armv7em`, `eCore_arm_armv7m`, and `eCore_mips32el`, instead set it back to true unconditionally. When both sides of a comparison are one of these three, the swapped call re-arms `try_inverse`, and the tail call back into `cores_match()` recurses forever. This is a tail call, so an optimizing compiler turns the recursion into a loop instead of a growing stack. That is why the process spins instead of crashing with a stack overflow. The three cases cannot simply leave `try_inverse` false like their siblings. `ArchSpec("mipsel").IsCompatibleMatch(ArchSpec("mips64el"))` is true today only because of this same swap: `eCore_mips32el`'s own rule says nothing about 64-bit MIPS, but `eCore_mips64el`'s rule accepts any 32-bit MIPS core with the same endianness, and only the inverted comparison reaches that rule. Instead, split the switch into a one-directional helper that never recurses, and try both directions from a plain, non-recursive wrapper: ``` cores_match(A, B) := cores_match_one_direction(A, B) || cores_match_one_direction(B, A) ``` This keeps every existing one-directional rule exactly as it was, including the mips32el/mips64el rule above, and makes a second retry impossible no matter what any case does. Adds two regression tests to ArchSpecTest.cpp. One asserts that the previously-hanging pairs now return false right away. The other locks in the two relationships that depend on checking both directions, so a future change cannot bring the recursion back by "fixing" the three cases the naive way. Assisted-by: claude
DeanSturtevant1
pushed a commit
that referenced
this pull request
Sep 29, 2026
…lvm#224001) Running the `HighlighterTests` unit test under AddressSanitizer aborts on every Swift test case, for example `SwiftComments`: ``` ==69424==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000008070 at pc 0x000116a1f36c bp 0x00016d07c3c0 sp 0x00016d07c3b8 READ of size 4 at 0x602000008070 thread T0 #0 0x000116a1f368 in eat_raw_str_part scanner.c:700 #1 0x000116a1b5f4 in tree_sitter_swift_external_scanner_scan scanner.c:858 #2 0x00012cc77420 in ts_parser_parse llvm#3 0x00012cc79afc in ts_parser_parse_string llvm#4 0x00010a3536a4 in lldb_private::TreeSitterHighlighter::Highlight(...) 0x602000008071 is located 0 bytes after 1-byte region [0x602000008070,0x602000008071) allocated by thread T0 here: #0 0x00012d68d560 in calloc #1 0x00012cc763b8 in ts_parser_parse #2 0x00012cc79afc in ts_parser_parse_string ``` `eat_raw_str_part` reads `state->ongoing_raw_str_hash_count` as its first statement, a 4 byte field, but the scanner state was allocated with: ``` void *tree_sitter_swift_external_scanner_create() { return calloc(0, sizeof(struct ScannerState)); } ``` `calloc` with an element count of 0 has no obligation to reserve room for `sizeof(struct ScannerState)`, so it works by accident, but is found by ASAN. Fix it by allocating one instance, matching the Rust scanner and the struct's actual use as a single persistent state object across calls. The existing `HighlighterTest.Swift*` tests already exercise this path end to end and catch the regression under AddressSanitizer; no new test is needed.
DeanSturtevant1
pushed a commit
that referenced
this pull request
Sep 29, 2026
…226936) Fixes llvm#191859. On Arm one of the functions has no name, which is a valid state. ``` Num frames: 7 0 frame #0: 0x092a151c a.out`baz at main.c:5:3 --name: baz 1 frame #1: 0x092a1540 a.out`bar at main.c:10:10 --name: bar 2 frame #2: 0x092a1560 a.out`foo at main.c:15:10 --name: foo 3 frame llvm#3: 0x092a158c a.out`main at main.c:20:10 --name: main 4 frame llvm#4: 0xf7ab939a libc.so.6` --name: None 5 frame llvm#5: 0xf7ab943e libc.so.6`__libc_start_main + 94 --name: __libc_start_main 6 frame llvm#6: 0x092a1434 a.out`_start + 40 --name: _start ``` The prefix provider needs to handle that possibility. Though the Python type annotations on ScriptedFrame say that the name methods return string, in reality they can return None, which the C++ sides expect. I will fix that in another PR.
DeanSturtevant1
pushed a commit
that referenced
this pull request
Sep 29, 2026
This test has been failing on AArch64 Linux recently. Either with SIGSEGV or SIGABRT (less often that one). I could reproduce it locally by varying system load, and got this out of a core file: ``` * thread #1, name = 'test_python_sto', stop reason = SIGSEGV: address not mapped to object (fault address=0xc17d18317552db80) * frame #0: 0x0000ef7dc72ac6cc libc.so.6`__GI_memchr at memchr.S:68 frame #1: 0x0000ef7dc727cf4c libc.so.6`_IO_getline_info(fp=0x0000b9b53a8bd180, buf="\xa9\xb4\t\xce}\xef", n=<unavailable> , delim=10, extract_delim=1, eof=0x0000000000000000) at iogetline.c:85:17 frame #2: 0x0000ef7dc727bdc4 libc.so.6`_IO_fgets(buf="\xa9\xb4\t\xce}\xef", n=<unavailable>, fp=0x0000b9b53a8bd180) at io fgets.c:53:11 frame llvm#3: 0x0000ef7dc80f2b80 liblldb.so.24.0git`lldb_private::IOHandlerEditline::GetLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&, bool&) + 996 frame llvm#4: 0x0000ef7dc80f41f4 liblldb.so.24.0git`lldb_private::IOHandlerEditline::Run() + 180 frame llvm#5: 0x0000ef7dc80bf614 liblldb.so.24.0git`lldb_private::Debugger::RunIOHandlers() + 128 frame llvm#6: 0x0000ef7dc80ccee8 liblldb.so.24.0git`std::_Function_handler<void* (), lldb_private::Debugger::StartIOHandlerTh read()::$_0>::_M_invoke(std::_Any_data const&) + 28 frame llvm#7: 0x0000ef7dc81e1608 liblldb.so.24.0git`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) + 124 frame llvm#8: 0x0000ef7dc72903c8 libc.so.6`start_thread(arg=0x000000000080e640) at pthread_create.c:442:8 frame llvm#9: 0x0000ef7dc72f9fdc libc.so.6`thread_start at clone.S:79 ``` What's happening is that the interpreter's input stream is set to stream A, then we reset it to the default, then close stream A. There may still be reads from stream A in flight when we close it, which lead to the crash. The solution is to wait on the interpreter thread to finish whatever it's doing. SBDebuger::Destroy does that. Normally that would be called by driver.cpp but it can be called on already destroyed objects. So for this test we'll call it twice, but that's not a problem.
DeanSturtevant1
pushed a commit
that referenced
this pull request
Nov 11, 2026
BPFASpaceCastSimplifyPass rewrites
`addrspacecast M->N (getelementptr (addrspacecast N->M p))` to
`getelementptr p`. When the inner cast has no other uses, the rewrite
erases it. That cast can also be the outer cast of another chain that is
still in the worklist. The pass then reads the erased cast. Clang
crashes on this code:
```c
#define __arena __attribute__((address_space(1)))
struct hdr { int len; int flags; };
int use(int *p);
int f(void __arena *buf, long off)
{
struct hdr __arena *h = (struct hdr __arena *)((char *)buf + off);
return use((int *)&h->flags);
}
```
```console
$ clang --target=bpfel -O2 -c bpf.c
devtools (dce2167): crash, SIGSEGV, Running pass "bpf-aspace-simplify" on function "test"
...
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and dumped files.
Stack dump:
0. Program arguments: clang --target=bpfel -O2 -c bpf.c -o bpf.o
1. <eof> parser at end of file
2. Optimizer
3. Running pass "function<eager-inv>(mem2reg,instcombine<max-iterations=1;no-verify-fixpoint>,simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-ra
4. Running pass "bpf-aspace-simplify" on function "test"
#0 0x0000000001f89b00 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/users/yatsenko/devtools/llvm/20261014/bin/clang-24+0x1f89b00)
#1 0x0000000001f8786c llvm::sys::CleanupOnSignal(unsigned long) (/data/users/yatsenko/devtools/llvm/20261014/bin/clang-24+0x1f8786c)
#2 0x0000000001ecc4f0 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
llvm#3 0x00007f268bc3fb30 __restore_rt (/lib64/libc.so.6+0x3fb30)
...
llvm#33 0x0000000000c390a5 _start (/data/users/yatsenko/devtools/llvm/20261014/bin/clang-24+0xc390a5)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 24.0.0git (https://github.com/llvm/llvm-project.git dce2167)
```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This updates the Bazel overlay following commit e5174fe:
:llvm_libc_types_float128from__support_math_ceilf128deps asinclude/llvm-libc-types/float128.his no longer included.:__support_cpp_bittoceilf128additional_deps forbit_cast.ceilf128math MPFR test target inlibc/test/src/math/BUILD.bazel.