[libc++] Assume that <atomic> is available (#199674)
We always define either `_LIBCPP_HAS_C_ATOMIC_IMP` or
`_LIBCPP_HAS_GCC_ATOMIC_IMP`, so we can remove any special handling of
not having an `<atomic>` header.
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
[21 lines not shown]
[TableGen] Recompute only the affected UberSet when inheriting reg units (#200962)
CodeGenRegBank::computeRegUnitWeights() runs a fixpoint over all registers;
normalizeWeight() calls the global computeUberWeights() -- which rescans
every UberRegSet, every register, and all of their register units -- each time
a register inherits register units from its subregisters.
Most of the time, we do better by just recomputing one register's
UberSet.
On AMDGPU (21266 registers) with this change, the "Compute reg unit
weights" phase drops from 3.19s to 0.70s (4.5x speedup) and
-gen-register-info improves overall from ~16.4s to ~14.0s.
Revert "[clang-cl] Add new option `/pathmap:<from>=<to>` to replace the path prefix <from> with <to>." (#201981)
Reverts llvm/llvm-project#198664
Causes test failures on
[llvm-clang-aarch64-darwin](https://lab.llvm.org/buildbot/#/builders/190)
bot.
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
[19 lines not shown]
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
[17 lines not shown]
Merge tag 'drm-fixes-2026-06-06' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly drm fixes, not contributing to things settling down
unfortunately. Lots of driver fixes for various bounds checks, leaks
and UAF type things, i915/xe probably the most sane, amdgpu has a mix
of fixes all over, then ethosu has lots of small fixes.
The problem of fixing thing in private has really hit us with the
change handle ioctl, and "Sima was right" and we should have disabled
the ioctl, since it was only introduced a couple of kernels ago and
failed to upstream it's tests in time.
The patch here fixes the problems Sima identified, but disables the
ioctl as well, with a list of known problems in it and a request for
proper tests to be written and upstreamed. It's a niche user ioctl
designed for CRIU with AMD ROCm, so I think it's fine to just disable
it.
[77 lines not shown]
Enforce an EdgeSet (implemented as a map) invariant: each map entry
represents at least one edge. That is, a map key should not exist if
the corresponding value is empty.
[clang-cl] Add new option `/pathmap:<from>=<to>` to replace the path prefix <from> with <to>. (#198664)
This option matches MSVC options and does the path substitution for the
file references in the preprocessor macros, debug and coverage information.
This option acts as a clang's ``-ffile-prefix-map=value`` and with some
known differences in behaviour with original CL's option that do not affect
the functionality:
* nomalizes the macro prefix map pathes -- removes `./` and uses the target's
platform-specific path separator character when exanding the preprocessor
macros -- ``-ffile-reproducible`` (but not the debug and coverage prefix maps).
* does not require ``/experimental:deterministic`` as by MSVC. It needed for
removing a hostname from a mangling hash gen, but clang-cl does not use
a hostname when generates the hashes.
Known issues:
* does not remap the pathes within PCH/PCM files.
[docs] Rewrite LangRef.md as Markdown
Tracking issue: #201242
This change migrates LangRef by itself, since it is quite a large
document with many idiosyncracies.
LangRef makes extensive use of definition lists, which apparently
require enabling the deflist MyST extension in Sphinx conf.py. In part
because definition list boundaries are controlled by indentation,
several of them required manual fixups to get the nesting right. Some of
the issues were pre-existing broken indentation, but this should now be
much better.
I have a verification script that tracks all anchors and ensures that
all previous anchors are carried over to the new document, so no
mid-document links are broken.
[CIR] Fix CIR Test failures after unnamed_addr restored to vtables (#201962)
We had previously removed the `unnamed_addr` keyword check from our
vtable checks for OGCG because it was temporarily not emitted in that
case. The OGCG output has been modified again, so we need to update our
checks again.
The CIR output has not changed.
[DirectX] Generate compiler version part in llc (#199699)
This change modifies DXContainerGlobals pass to generate compiler
version (VERS) part in DXContainer.
VERS part allows consumers to information about compiler version used to
build shader.
When debug info PDB file creation will be implemented, VERS part should
go to PDB file.
APEI: Provide more info on fatal hardware errors
This change refactors fatal error delivery via APEI and prints more info:
- Makes the NMI handler call into the ge handler to establish a common
code flow, no matter how the error is delivered
- Adds the FRU to the panic string so as to provide more information than
just "APEI Fatal Hardware Error!" such as
"APEI Fatal Hardware Error: PcieError"
- Prints more details about fatal pcie errors. Note that we skip acquiring
Giant on fatal errors
- Hexdumps the full GED data on fatal errors, so as to facilitate
offline data analysis
Reviewed by: imp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D57417
[lldb] Skip plugin teardown when exiting without Terminate (#201739)
`import lldb` auto-calls SBDebugger::Initialize() but never Terminate().
The g_debugger_lifetime is a deliberately-leaked ManagedStatic, so the
PluginInstances containers are still populated when their static
destructors run at process exit. That tripped the "forgot to unregister
plugin?" assert, and once the assert was gated the dynamically-loaded
plugin map's PluginInfo terminate callbacks ran against PluginInstances
mutexes that had already been destroyed.
This only surfaces with LLDB_ENABLE_DYNAMIC_SCRIPTINTERPRETERS, where
`_lldb` is the script-interpreter plugin dylib and liblldb comes in as a
dependency that exit() finalizes. A static build leaks identically but
never reaches those destructors, so the bug stayed latent.
Track an explicit lifecycle (Uninitialized/Initialized/Terminated) in a
single never-destroyed PluginRegistry. ~PluginInstances only checks for
leftover registrations once Terminate() has run, and the map (never torn
down at exit) only runs its terminate callbacks during an explicit
clear, while every container is still alive.
