[Support] Make formatted_raw_ostream::has_colors() delegate to the wrapped stream (#223092)
Without this override, has_colors() falls back to is_displayed(), which
isn't always expected to give the same answer as the underlying stream's
has_colors().
This also fixes a compile-time regression when the underlying stream is
a raw_fd_ostream: raw_fd_ostream::has_colors() memoizes its result, but
without this override that memoization was bypassed in favor of the
uncached is_displayed(), issuing an isatty() syscall on every call.
#202441 is what surfaced this, by adding a has_colors() call to
TextDiagnostic's per-character hot loop.
rdar://186469856
Co-authored-by: Fred Riss <friss at apple.com>
[NFC] Hoist DiagOpts.showColors(OS.has_colors()) out of emitSnippet's per-character loop (#223095)
The result of DiagOpts.showColors(OS.has_colors()) does not change while
printing a single source snippet, so recomputing it for every character
is unnecessary. Compute it once per snippet instead.
rdar://186469856
Co-authored-by: Fred Riss <friss at apple.com>
18412 libproc checks core files for an ELF OSABI that is never set
Reviewed by: Robert Mustacchi <rm at fingolfin.org>
Approved by: Dan McDonald <danmcd at oxide.computer>
[llvm][test] Quote args in -print-on-crash test (#223472)
Passing `-passes=cgscc(trigger-crash-cgscc)` in lit works because of its
shell handling, but fails when passing directly to a shell: ` syntax
error near unexpected token '('`.
[TableGen] Expose remapRegClassByHwMode() helper in AsmMatcher
This is useful to map from a ByHwMode MCK_* value to the actual resolved
MCK_* type. This is needed for #177073 where we would otherwise have to
add the manual logic to do this remapping (which is the approach I
previously used). Move RegClassByHwModeMatchTable to file scope and
provide a remapRegClassByHwMode() helper function in the generated
AsmMatcher. Currently only used for RISC-V, but I assume other targets
could also make use of this in the future. But even if not, I think it's
cleaner to have this as a helper rather than an inline array inside the
matcher function.
This change was created with the help of AI tools.
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/223302
[SandboxVec][VecUtils][NFC] BndlRef helper class (#223074)
During debugging we need to be able to easily print a bundle of
instructions or values. Up until now we would use VecUtils::dump(Bndl).
But a much nicer API would be Bndl.dump().
To support such an API this patch is introducing BndlRef, a subclass of
ArrayRef with the additional feature of supporting print(OS) and dump()
for Value and Instruction contents.
[mlir][AMDGPU] Keep `chipset` as a deprecated alias for `arch`
Renaming the option meant every existing invocation of these passes had
to be updated in lockstep. Accept the old spelling instead: `chipset` on
`convert-amdgpu-to-rocdl`, `convert-gpu-to-rocdl`, `convert-arith-to-amdgpu`,
`convert-math-to-rocdl` and `amdgpu-emulate-atomics`, and `chip` on
`gpu-lower-to-rocdl-pipeline`, which is what each of them was called
before the rename.
`arch` wins whenever it names a target; the alias is consulted only when
`arch` is still at the sentinel that means "no target given", so with
neither given the error still names the unusable default rather than an
empty string, and a stale alias value is reported as itself.
[mlir] Migrate AMDGPU/ROCDL to targets, not chipset versions
**migration tl;dr:** `chipset=` becomes `triple=`, migrate off of
`amdgpu::Chipset` to `ROCDL::TargetInfo`, and eventually change
`gfxXYZ` to `amdgpuX.YZ-amd-amdhsa` in that `triple` argument.
`amdgpu::Chipset` was an awkward hack that was hard to keep up to date
with changes in the compiler/new architectures, and didn't properly
support generic targets (and has been strongly disfavored by the
compiler team).
This PR replaces `amdgpu::Chipset` with `ROCDL::TargetInfo`, a
structure that uses LLVM's TargetParser and the underlying LLVM
features tables to get the real nature of the target being compiled
for.
This also helps MLIR move to
new-style (`-mtriple=amdgpuX.YZ-amd-amdhsa`) over "old
style" (`-mtriple=amdgcn-amd-amdhsa -mcpu=gfxXYZ`) triples.
[40 lines not shown]
[mlir][AMDGPU] Take an `arch` target ID instead of triple/chip/features
`features` was a general `-mattr` string, which needed a general feature
parser and let callers ask for arbitrary combinations we have no interest
in supporting. In practice the only things anyone sets are the wavefront
size and the xnack/sramecc settings that come off a device query.
Replace `triple`, `chip` and `features` with a single `arch` option that
names the target the way Clang does, parsed by `llvm::AMDGPU::TargetID`
rather than by hand. It accepts
- a processor, with optional target-ID modifiers: `gfx942`,
`gfx942:xnack+`, `gfx9-4-generic`;
- a triple: `amdgpu9.42-amd-amdhsa`;
- a full target ID: `amdcgn-amd-amdhsa--gfx90a:sramecc+:xnack-`, which
is what `rocminfo` prints for a device's ISA, so that output can be
pasted straight in.
Since `chipset=gfx942` becomes `arch=gfx942`, migration is a rename.
[22 lines not shown]
[mlir][ROCDL] Carry `arch`'s xnack/sramecc onto the module
`rocdl-attach-target` rejected a target ID that pinned xnack or sramecc,
because `#rocdl.target` feeds a TargetMachine and the backend no longer
accepts those two as subtarget features. Now that the module attributes
exist, migrate them instead of refusing: `TargetInfo` gains
`migrateArchFeaturesToModuleFlags`, which records the settings the target
ID pinned as `rocdl.xnack` / `rocdl.sramecc` on a module, and
`rocdl-attach-target` calls it on each module it attaches to.
A setting the target ID leaves open, or that the GPU does not support, is
left alone rather than written as false: an absent flag means "either",
so writing false would be a different request. That also means an
attribute already on the module survives an `arch` that says nothing
about the feature, while an `arch` that does pin it wins as the more
specific request.
[mlir][AMDGPU][NFC] Pre-commit tests for incorrect version checks
There'll be a refactoring from `amdgpu::Chipset` to
`ROCDL::TargetInfo`, thus also moving from chip version checks to
features checks. This commit adds tests for incorrect lowerings that
were allowed by the current code.
- gfx90c is >= gfx90a but stil needs atomic emulation (it doesn't
have buffer fmax and so on).
- gfx90c is also >= gfx90a but has no barrier back-off, so it needs
the inline asm workaround around `s_barrier` that it isn't getting
- gfx908 doesn't have a packed fp16 atomic add but we thought it did
- gfx950 is mistakenly allowing xf32 MFMAs
- gfx1200 is allowing permlane_swap instructions that it doesn't have
- gfx11.7 should be allowing OCP FP8 conversions but isn't on the list
This also cleans up some redundant tests with a --check-prefixes
AI disclosure: Claude found these and wrote the tests.
[2 lines not shown]
x11/bosd: new port
X11 on-screen display engine: PNG glyphs, countdown digits,
outlined text, and a gauge bar. A warm daemon per channel
repaints in place.
Approved by: fuz (mentor)
Reviewed by: fuz (mentor), jrm (co-mentor; previous revision)
Differential Revision: https://reviews.freebsd.org/D59517
[libc] Restrict sysconf/confstr to full-build mode. (#223103)
`sysconf` (and its sibling `confstr`) from `<unistd.h>` return some
values specific to the kernel/environment,
and some values specific to the system library (e.g. features available
in system library's pthread implementation).
Using LLVM-libc sysconf in overlay mode is inherently problematic - we
don't know what features host libc has,
and trying to reverse-engineer it would be brittle. Since we include
host libc's `<unistd.h>`, we can't even know in
advance what `_SC_` values or what macros would be available there, so
the portable implementation of `sysconf`
will be convoluted, and there's little benefits to it anyway.
Conversely, making sure that our `sysconf` implementation only compiles
against LLVM-libc's own headers will allow
us to precisely handle macro / features that we know are available /
supported.
[6 lines not shown]
Reject recursive permissions changes on S3 bucket mountpoints
filesystem.chown, filesystem.setperm and filesystem.setacl now refuse
a recursive change whose path is the mountpoint of a dataset consumed
by an S3 bucket, or that would traverse into one from above. The error
points the caller at the bucket's s3data directory instead, since a
recursive change over the whole bucket may have undefined behavior and
expose security risks.
[Flang][HLFIR] Bail out of EOSHIFT simplification for polymorphic arrays (#223118)
Consider the following code
```
module m
type Base
integer :: i = 8
end type
type, extends(Base) :: Child
integer :: j = 9
end type
end module
program argumentKeyword002
use m
class(*), pointer :: b1(:,:,:), boundVal
allocate(b1(3,2,2), SOURCE=reshape((/(i,i=1,12)/), &
[28 lines not shown]
games/anki: Update to 26.09
* Migrate to Yarn v4 to be in sync with upstream. To ensure that the
preinstalled Yarn v4 is actually used, a few minor workarounds and a
new variable PREINSTALLED_YARN are required.
The latter is necessary because, with Yarn v2 and newer, environment
variables prefixed with YARN_ can no longer be used.
* Sort pkg-plist while I'm here.
Changelog:
https://github.com/ankitects/anki/releases/tag/26.09
MFH: 2026Q3
Security: ce54d883-b060-11f1-b187-901b0edee044
