[X86] Don't fold loads from non-fixed stack objects into tail calls (#221243)
Fixes #216504
The callee of a tail call can be folded into the jump as a memory
operand (`TCRETURNmi64`). That jump runs after the epilogue, so the
operand is resolved relative to the incoming stack pointer, which only
works for fixed objects such as incoming arguments. Here the callee was
a `volatile` local, so the load stayed on the stack and got folded,
while a variable-index extract from a 256-bit vector went through a
32-byte stack temporary and forced dynamic realignment. Once the stack
is realigned a local has no static offset from the incoming stack
pointer, and PEI tripped the assertion. The sibcall eligibility check
does look at realignment, but it runs before legalization, so it never
saw the temporary. Spill slots created during register allocation can
cause the same thing, so no check at that point can be complete.
The fold is now refused whenever the load's address may use a non-fixed
frame index, in `checkTCRetEnoughRegs`, which gates both the
[5 lines not shown]
[CIR] Derive lowering attr names from cppClassName, not the def name
CIRLoweringEmitter built its CXX_ABI_ALWAYS_LEGAL_ATTRS entries with
GetOpCppClassName, which splits the TableGen def name at the first
underscore. That works only while every def is named CIR_<CppClassName>Attr.
When one is not, the emitter writes an `isa<>` for a class that does not
exist, and the failure lands as a compile error in generated code.
Attributes carry the authoritative name in cppClassName, which
GenerateAttrToValueVisitor was already reading. Factor that out as
GetAttrCppClassRef and use it for both attribute paths. GetOpCppClassName
stays for operations.
NFC, and checkable. No CIR attribute overrides cppClassName, so the generated
CIRLowering.inc is byte-identical.
[CIR] Migrate the FPClassTest bit enum and unquote its flags
cir.is_fp_class printed its flags inconsistently. Single-bit values came out
bare, as in `fcSNan`, while group values and combinations came out quoted, as
in `"fcInf"` and `"fcSNan|fcNegInf"`. That comes from I32BitEnumAttr setting
printBitEnumQuoted, which EnumAttr.td keeps only for backwards compatibility.
Clearing the bit and using the `enum` directive selects the separator-aware
parser and printer, so every value now spells unquoted:
cir.is_fp_class %x, fcSNan|fcNegInf : (!cir.float) -> !cir.bool
The enum also drops its specialized IntegerAttr for a CIR_EnumAttr wrapper,
giving it the standalone spelling `#cir.fp_class<fcSNan|fcNegInf>`. This
changes operation syntax, so it updates 37 CHECK lines.
[CIR] Drop dead ceremony around the CIR enum attributes
Five things that no longer earn their place in the CIR enum attribute
machinery.
CIR_CleanupKindAttr carried three. Its cppClassName restated the default
AttrDef already derives. Its skipDefaultBuilders plus hand-written
AttrBuilder existed only to default $value to CleanupKind::All, which no
caller relies on, so the generated builders stayed suppressed for nothing.
And its summary and description restated the name, overriding the enum's own
"cleanup kind" that EnumAttr would otherwise inherit. The isNormal, isEH and
isNormalAndEH helpers stay.
CIR_TLSModelAttr's summary restated its name the same way, so only that goes.
CIR_DefaultValuedEnumParameter has never had a user.
NFC.
[CIR] Move the CIR enums off the legacy EnumAttrInfo hierarchy
MLIR has two enum hierarchies. `EnumAttrInfo` doubles as an `IntegerAttr`
constraint, so every CIR enum had to clear `genSpecializedAttr` to say it did
not want one. `EnumInfo` describes a C++ enum and nothing more.
Derive the CIR bases from `I32Enum`, `I64Enum` and `I32BitEnum`, and widen
`CIR_EnumAttr` to the `EnumInfo` that upstream `EnumAttr` already takes. The
flag no longer exists to clear. `FPClassTestEnum` gets unquoted printing from
`BitEnumBase` rather than overriding `printBitEnumQuoted`, and
`CIR_KnownFuncKind` drops a `parameterPrinter` the generated `operator<<`
now covers, still spelling `#cir.func_identity<"std::find">`.
AMDGPU wraps an `I32Enum` in an `EnumAttr` with this same bracketed format.
Parsing moves to the generated `FieldParser`, whose diagnostic names the
accepted spellings, so two `expected-error` lines change. Generated attribute
code drops 16 KB as 28 inlined parsers collapse into it.
[CIR] Move the CIR enums off the legacy EnumAttrInfo hierarchy (#220889)
MLIR has two enum hierarchies. `EnumAttrInfo` doubles as an
`IntegerAttr`
constraint, so every CIR enum had to clear `genSpecializedAttr` to say
it did
not want one. `EnumInfo` describes a C++ enum and nothing more.
Derive the CIR bases from `I32Enum`, `I64Enum` and `I32BitEnum`, and
widen
`CIR_EnumAttr` to the `EnumInfo` that upstream `EnumAttr` already takes.
The
flag no longer exists to clear. `FPClassTestEnum` gets unquoted printing
from
`BitEnumBase` rather than overriding `printBitEnumQuoted`, and
`CIR_KnownFuncKind` drops a `parameterPrinter` the generated
`operator<<`
now covers, still spelling `#cir.func_identity<"std::find">`.
[Support][Caching] Don't use `mmap` in `localCache`, on NFS
When the cache directory is on an NFS, we may hit a SIGBUS signal
when there is contention on the cache.
This happens typically with MPI jobs running on an NFS mounted $HOME
directory.
If we execute through the regular `read()` path, we also fail with a
`Stale file descriptor` error. But at least this path is properly handled
and we can continue without using the cache.
To achieve this, we pass `OnNFS` to `IsVolatile` and `RequiresNullTerminator`,
which makes `shouldUseMmap` return `false`.
[LoopSafetyInfo] Store Loop and automatically compute (NFC) (#221238)
This makes two changes:
* LoopSafetyInfo is bound to a single loop. Store the Loop in the ctor,
so it does not need to be passed to individual queries.
* Automatically compute LoopSafetyInfo on construction, instead of in a
separate call. This is mostly to clarify that (contrary to the doc
comment) nobody is actually trying to invalidate LoopSafetyInfo by
rerunning computeLoopSafetyInfo().
This makes it easier to change implementation details, like computing
information lazily.
databases/pgterm: Update to 0.1.4
Upstream 0.1.4 declares the fake-pgbot test fixture as a [[bin]] target,
which cargo then installs alongside pgterm. Restrict the install to the
pgterm binary, matching upstream's own release packaging.
jujutsu: drop vendored fish completion
A user reported that bookmark and revision completions do not work in fish.
It turns out that the static completion we install in vendor_completion.d
gets in the way. jj has supported (experimental) dynamic completetions out
of the box since 0.24.0, which works without config for fish >=4.0.2
Users of fish 3 will need to "jj util completion | source" to install the
completions.
ok kn
[lldb][test] Rewrite Watchpoint/SetErrorCases as API test (#221563)
This test is randomly failing on macOS bots with this error:
```
error: Command requires a process which is currently stopped.
```
There is no test logic in shell tests that can diagnose what is going on
with the process, so this patch rewrites this test as an API test where
we have better error handling.
Reapply [Clang][CodeGen] Use ptrtoaddr for pointer diff (#210729) (#221675)
Reapply https://github.com/llvm/llvm-project/pull/210729 without change
after https://github.com/llvm/llvm-project/pull/221188, which should fix
the miscompiles this change exposed.
-----
We don't have to expose the provenance of pointers for pointer
subtraction, so use ptrtoaddr instead of ptrtoint if -fwrapv-pointer is
not set.
Co-authored-by: Alexis Engelke <engelke at in.tum.de>
[C++20] [Modules] [ScanDeps] Scan results for module map file (#221652)
Previously we described the trick to use module map to import std module
implicitly. But in practice, this may not work as build tools can't get
the dependencies.
In this patch, we updated clang-scan-deps to report the dependencies
between consumers and the corresponding module described in module map
file in P1689 format. The P1689 format in clang-scan-deps is the defacto
dependency description between compiler and build tools. This helps end
users to use the trick without waiting for the support from various
build tools.
[InstSimplify] Improve coverage for zero-shift-guard folding for rotate (#217033)
The current logic responsible to fold zero-shift-guard performed the
folding only when the shift amount is exactly zero. But, the guard could
be eliminated as long as the funnel shift instruction is performing a
bitwise rotate and the shift amount is a multiple of the bitwidth of the
value being rotated. This commit makes this change.
Fix various minor things in our bpf implementation
In userland it is possible to call bpf_filter / pcap_offline_filter
with unverified bpf programs. Because of this harden bpf_filter further
by adding the following extra checks:
- Ensure that load and store operations to the scratch memory store are
always bound checked.
- Ensure that no division or modulo by zero is done.
- No longer do shift operations with a too large shift exponent. Instead
zero out the result.
- No longer call abort on unknown instructions when bpf_filter is run
in userland. Use the same return 0 as is already done in the kernel.
On top of this ensure that no unhandled instruction encoding makes it
through bpf_validate by using the same case handling as bpf_filter.
This are fixes for libpcap CVE-2026-0799, CVE-2026-6244, CVE-2026-6554,
CVE-2026-31911. None of the above CVEs are applicable to or kernel since
[2 lines not shown]
x11/mangobar: Add new port
Mangobar is a Wayland status bar for mangowm, built on wlr-layer-shell. It
reads all of its runtime settings from JSONC and CSS; there are no hard-coded
module defaults beyond sample files.
The system tray (StatusNotifierItem / DBusMenu) is inspired by swaybar and
waybar.
https://github.com/mangowm/mangobar
[CIR] Move the CIR enums off the legacy EnumAttrInfo hierarchy
MLIR has two enum hierarchies. `EnumAttrInfo` doubles as an `IntegerAttr`
constraint, so every CIR enum had to clear `genSpecializedAttr` to say it did
not want one. `EnumInfo` describes a C++ enum and nothing more.
Derive the CIR bases from `I32Enum`, `I64Enum` and `I32BitEnum`, and widen
`CIR_EnumAttr` to the `EnumInfo` that upstream `EnumAttr` already takes. The
flag no longer exists to clear. `FPClassTestEnum` gets unquoted printing from
`BitEnumBase` rather than overriding `printBitEnumQuoted`, and
`CIR_KnownFuncKind` drops a `parameterPrinter` the generated `operator<<`
now covers, still spelling `#cir.func_identity<"std::find">`.
AMDGPU wraps an `I32Enum` in an `EnumAttr` with this same bracketed format.
Parsing moves to the generated `FieldParser`, whose diagnostic names the
accepted spellings, so two `expected-error` lines change. Generated attribute
code drops 16 KB as 28 inlined parsers collapse into it.
[CIR] Migrate the FPClassTest bit enum and unquote its flags (#220888)
cir.is_fp_class printed its flags inconsistently. Single-bit values came
out
bare, as in `fcSNan`, while group values and combinations came out
quoted, as
in `"fcInf"` and `"fcSNan|fcNegInf"`. That comes from I32BitEnumAttr
setting
printBitEnumQuoted, which EnumAttr.td keeps only for backwards
compatibility.
Clearing the bit and using the `enum` directive selects the
separator-aware
parser and printer, so every value now spells unquoted:
cir.is_fp_class %x, fcSNan|fcNegInf : (!cir.float) -> !cir.bool
The enum also drops its specialized IntegerAttr for a CIR_EnumAttr
wrapper,
giving it the standalone spelling `#cir.fp_class<fcSNan|fcNegInf>`.
[CIR] Fix address space issues related to SPIR/SPIR-V targets (#220982)
This adds support for address space lowering for spir/spir64 (not v)
which are still widely used in OpenCL testing despite spirv32/spirv64
targets existence. This also corrects alloca address space for all
mentioned targets from default to private which is semantically correct
for them and avoids emission of spurious address space casts.
Assisted-by: claude in test cases updating
redis: Replace interpreter for scripts/build.sh.
Despite a comment at the top of the script saying it is designed for POSIX
sh, it uses the non-portable 'local' keyword.
sched_4bsd: Allocate runqueues only for present CPUs
4BSD has been allocating an array of MAXCPU runqueues, runq_pcpu[],
instead of one runqueue per actually present CPU. On amd64, MAXCPU is
1024 and 'struct runq' is 4128 bytes, causing runq_pcpu[] to take more
than 4 MiB of memory. On the vast majority of current systems, which
have at most 32 cores with SMT, this is a waste of memory.
Besides providing per-CPU runqueues, runq_pcpu[] has also been used to
determine the CPU ID of a given thread's associated runqueue through
pointer arithmetic.
Since per-CPU structures are only allocated for present CPUs, in order
to save space, move the runqueues to per-CPU fields and, for each thread
('struct ts_sched'), replace its runqueue pointer by the CPU ID of the
runqueue it is in (new 'ts_rqcpu' field). Set the thread's CPU ID to
the special NOCPU value when it is running on the global runqueue.
Drop the SKE_RUNQ_PCPU() macro as it is now simply equivalent to
[13 lines not shown]
sched_4bsd: Remove obsolete SMP scaling for ticks per priority level
The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit
b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP
case. ...") to leave more discrimination room for multiple CPUs possibly
adding their ticks to the same 'struct ksegrp' (but also slightly
changing how CPU hogs are penalized).
Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced
the current thread-based code, where tick accounting is only done on the
current thread, which renders this trick obsolete on !KSE.
Finally, when KSE was removed, the trick became generally obsolete.
The trick is actually even harmful because it changes the intended
behavior of priorizing more the CPUs that use the less ticks (and so,
impairs boosting "interactive" processes).
Remove it now. Clamping of 'ts_estcpu' and its relation to the
[8 lines not shown]
sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads
We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of
ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any
value in the timeshare range") in order to use more than a fixed number
(40) of all the available priority levels in the timeshare range (136
before the 256-queue runqueue work, 224 now) to take into account the
number of ticks a thread has run ('ts_estcpu').
In the computation of a new thread's priority (resetpriority()), in
addition to the "ticks running" contribution, the final priority also
includes a "nice" value contribution. The final value is clamped into
the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range.
Problem is that the new "ticks running" contribution now can lead to
a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus
finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all
out-of-bound values. In particular, this can conflate CPU-hungry
threads. With at least two of them competing on the same CPU, with an
[22 lines not shown]
