x11/xconfig: Update to 3.6
Remove unused packages before setting up drivers, so an early exit
during NVIDIA setup no longer leaves VM guest packages installed.
Remove unused packages before setting up drivers
Package removal was queued and only run after main returned, so any
early exit during driver setup (e.g. NVIDIA) skipped it and left
packages like virtualbox-ose-additions installed. The remove_*
functions now delete right away, before the setup functions run.
Also drop the leftover remove_qemu calls, which aborted the script
under set -e, and stop generating xorg.conf with X -configure for
NVIDIA.
[KnownFPClass] Refactor NaN sign encoding for KnownFPClass (#220606)
Part of https://github.com/llvm/llvm-project/issues/217072
Replaces the `struct` layout for `KnownFPClass`
```c++
struct KnownFPClass {
FPClassTest KnownFPClasses;
std::optional<bool> SignBit;
};
struct KnownFPClass {
FPClassMask KnownFPMask;
};
```
I also added conversion functions between `FPClassTest` and
`FPClassMask`.
[AMDGPU] Report packed F32 unpacking as a change (#234859)
SIPreEmitPeephole::run did not set Changed after unpacking, so when
unpacking was the only change the new pass manager kept every cached
analysis and the legacy one saw an unchanged function.
Assisted-by: Claude Opus 5.5
Use loadfirmware(9) to load the rge(4) microcode from /etc/firmware
instead of hard-coding a gigantic firmware into the kernel.
suggested by deraadt@
ok mlarkin@
[lldb] Report why a script interpreter is unavailable (#235947)
When Python can't be loaded, no plugin registers for it and LLDB falls
back to ScriptInterpreterNone, which claims LLDB was built without
scripting support. The real error was dropped during initialization.
Record the error per language in the PluginManager where the failure
happens, and pass the requested language to the create callback so
ScriptInterpreterNone can report it from the relevant commands.
For a language LLDB was built with but has no recorded error, report
that its plugin wasn't loaded.
rdar://190746062
Assisted-by: Claude
powerpc: Avoid deadlock when CPUs exchange threads
The PowerPC context switch waited for the incoming thread to leave
blocked_lock before releasing the outgoing thread. If two CPUs selected
each other's running threads concurrently, both CPUs waited for the
other to perform the release and neither could progress. This appeared
as intermittent boot hangs under QEMU MTTCG when taskqueue threads were
bound to opposite CPUs.
8df2e5421468 ("powerpc: put the isync inside the TD_LOCK()...")
attempted to fix the same hang by moving isync into the polling loop.
That did not address the circular wait: isync cannot cause either CPU to
execute the release store after the loop. It only added context
synchronization to failed iterations and changed timing. Move isync back
to the successful exit, which preserves acquire ordering for subsequent
context loads.
Match the ordering used by other architectures: publish the outgoing
thread's new lock before waiting for the incoming thread. Apply the
[22 lines not shown]
[DebugInfo] Preserve original value when replacing instructions (#234978)
There are several places in `correlated-propagation` where an
instruction is replaced without salvaging the debug info. The value
computed by the new instruction may be different to the original that
was replaced. This leads to debuggers like lldb reporting incorrect
values for variables (reporting the value of the new instruction).
This PR makes sure the compiler salvages the debug information of the
replaced instructions before replacing them.
(See issues #218621, #218622, #218623 and #218366)
(Pinging @MrEven132, since I can't add as a reviewer)
[DebugInfo] Salvage replaced and instructions (#234693)
When `correlated-propagation` removes and instructions, it doesn't
correctly salvage the debug info. This leads to variables having
incorrect debug info. This patch makes sure we salvage the debug info
before removing the instructions
(See https://github.com/llvm/llvm-project/issues/219940)
Pinging @MrEven132 since I can't seem to add as a reviewer
powerpc: Avoid deadlock when CPUs exchange threads
The PowerPC context switch waited for the incoming thread to leave
blocked_lock before releasing the outgoing thread. If two CPUs selected
each other's running threads concurrently, both CPUs waited for the
other to perform the release and neither could progress. This appeared
as intermittent boot hangs under QEMU MTTCG when taskqueue threads were
bound to opposite CPUs.
8df2e5421468 ("powerpc: put the isync inside the TD_LOCK()...")
attempted to fix the same hang by moving isync into the polling loop.
That did not address the circular wait: isync cannot cause either CPU to
execute the release store after the loop. It only added context
synchronization to failed iterations and changed timing. Move isync back
to the successful exit, which preserves acquire ordering for subsequent
context loads.
Match the ordering used by other architectures: publish the outgoing
thread's new lock before waiting for the incoming thread. Apply the
[22 lines not shown]
[scudo] Omit quarantine state when QuarantineDisabled (#235117)
When QuarantineDisabled is true, GlobalQuarantine still occupies 192
bytes (three cache lines) in Allocator and QuarantineCache occupies 32
bytes (plus 32 bytes of cache-line tail padding) in each TSD.
Allows the now empty classes to be empty by using [[no_unique_address]].
security/vuxml: fix build
Correct the <dates/> sections of two recently updated vulnerabilities
from 2025. These errors were caught by "make validate".
Fixes: c943f0b840f2 ("security/vuxml: adjust linux-rl9-libxslt package for b0a3466f-5efc-11f0-ae84-99047d0a6bcc (+)")
Fixes: ec5bfc412d3c ("security/vuxml: adjust linux-rl9-libxml2 package version for abbc8912-5efa-11f0-ae84-99047d0a6bcc (+)")
Pointy hat to: fluffy
[compiler-rt][Android] Filter out linker warnings from stderr in android_run.py (#235973)
Older Android dynamic linkers (e.g. API 24) print `WARNING: linker: ...`
lines to stderr for newer ELF flags/tags such as `DT_FLAGS_1=0x8000001`
(`DF_1_PIE`) and `DT_AARCH64_BTI_PLT` (`0x70000001`). When these lines
are emitted at startup or when spawning `llvm-symbolizer`, they break
tests using `count 0`, `CHECK-NEXT`, or `CHECK-NOT` on
https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-android.
Strip `^WARNING: linker: .*` lines from stderr in `android_run.py`,
matching `libcxx/utils/adb_run.py`.
Assisted-by: Gemini
www/mod_wsgi4: a port for mod_wsgi 4.9.4 for python 2.7
This brings back mod_wsgi 4.9.4 which is the last supported
version for python 2.7.
This is specifically for clusteradm infrastructure and not
as a port for normal users.
Note this currently clashes with www/mod_wsgi as it also
builds and installs the module as "mod_wsgi.so".
Approved by: clusteradm
[lldb] Return llvm::Error from breakpoint callback setters (#235964)
Have ScriptInterpreter::SetBreakpointCommandCallback and
SetBreakpointCommandCallbackFunction return llvm::Error instead of
Status, converting back to SBError at the API boundary.
Requiring the error to be handled surfaces two dropped errors:
- The Python SetBreakpointCommandCallbackFunction ignored the result of
generating the callback.
- Deserializing a breakpoint reported the outer, still-empty Status
instead of the script error.
Assisted-by: Claude
[lldb][CMake] Link static libraries before liblldb (#235949)
The static linker resolves each undefined symbol from the first library
on the command line that defines it. When liblldb re-exports private
symbols, for example with LLDB_ENABLE_DYNAMIC_SCRIPTINTERPRETERS, tools
that list liblldb before lldbHost and lldbUtility bind part of those
libraries to liblldb and the rest to their own static copies.
List liblldb last so the static libraries take precedence. On Linux,
`lldb_prevent_liblldb_symbol_interposition` already covers this with
--exclude-libs.
[ci] Create a monorepo-wide workflow to submit to LNT (#235863)
Lift the libc++ specific workflow into one that is clearly decoupled
from libc++ and can be reused by other projects in the monorepo. This is
intended to support other projects submitting data into LNT.
One interesting question is whether we want all jobs to use the same
token. In LNT v5, a token can be scoped to specific test suites (e.g. a
token can be limited to submitting only to the libcxx test suite). Right
now, this workflow assumes that the token in use can submit to the
provided suite, and all submissions would use the same token, which
would be unscoped.
I think this is fine, at least for now, but we could potentially revisit
this decision in the future.
