[PassManager] Mark Loop RequireAnalysis as OptionalPassInfoMixin (#196345)
\#192120 marked this as RequiredPassInfoMixin, deviating from previous
behavior. This is probably fine for Function/Module analyses, but
doesn't work well for loop analyses in the case that we have a loop in
an optnone function that is not in LCSSA. The LCSSA pass will not run
because it is optional, the analysis will get computed, and then we
assert because the loop is out of LCSSA at the end of the LPM.
Restore the old behavior of just not marking the pass as required as it
seems reasonable enough.
devel/esbuild: Add note for future updates
esbuild is tied to a source package used for chromium & iridium,
let chromium@ know as a courtesy to avoid breakage.
Reported by: des
Sponsored by: SkunkWerks, GmbH
[flang] Implement -Wno-<warning> flags for driver diagnostics
Utilize clang::ProcessWarningOptions function to process -Wno-... options.
This has the side effect that without additional changes it would cause
driver warnings to become errors with -Werror. That would be a change
from the existing behavior, so make sure that these warnings remain
uneffected.
Modify the diagnostic emitter to add the disabling option at the end of
the emitted diagnostic.
Fixes https://github.com/llvm/llvm-project/issues/195921
Pull up following revision(s) (requested by kre in ticket #267):
lib/libc/gen/sysctl.c: revision 1.40
lib/libc/gen/sysconf.3: revision 1.58
share/man/man7/sysctl.7: revision 1.172
lib/libc/time/localtime.c: revision 1.154
include/time.h: revision 1.57
PR lib/60219 -- Fix sysconf(_SC_TZNAME_MAX)
That value is supposed to be the minimum value allowed for
the maximum length of a timezone abbreviation. It cannot
be something larger than is allowed for that (and NAME_MAX
has nothing to do with it)
It defines the max lengths allowed for the words in
TZ=Frankenstein-7Monster-6[transition rules]
in old style POSIX TZ variable settings - the POSIX required
minimum value is 6 (so "Frankenstein" would not fit in a minimalist
[12 lines not shown]
[libclc] Fix using normalized triple for the directory name (#194607)
Summary:
libclc needs to normalize triples, mostly on account of the fact that
things like spv and clspv aren't real triples but are used anyway. That
is, we convert the user-value to whatever is passed to `--target=`. The
problem is that we were not using the normal triple for the installation
directory, so something like `spirv64-mesa32-unknown` would be installed
in `spirv64--`.
This *might* have the side effect of putting these in
`spirv64-unknown-unknown`. I actually do not know if that's a problem
with the clang handling, I'll double check.
Pull up following revision(s) (requested by kre in ticket #266):
external/bsd/top/dist/display.c: revision 1.11
external/bsd/top/dist/commands.c: revision 1.9
external/bsd/top/dist/machine/m_netbsd.c: revision 1.31
external/bsd/top/dist/utils.c: revision 1.7
external/bsd/top/dist/utils.c: revision 1.8
external/bsd/top/dist/utils.c: revision 1.9
<stype.h> "negative" char usage issue fixed.
sprintf/ctype police
Undo earlier meaningless change
Revert my botched change (rev 1.7, 2026-04-18 19:42:21 +0000) which
had the parens in the wrong place, which made it useless (pointed out
offlist by rillig@ - thanks). The change was made unnecessary by
christos later change (rev 1.8, 2026-04-18 21:37:04 +0000), so there
is no point fixing it, just make it go away.
Fix return value logic in pmap_changebit() (used to implement
pmap_clear_reference() and pmap_clear_modify()): We need to seed
the "combined_pte" with the mod/ref information stashed in the
vm_page because all of the mappings to the page may have already
been removed via pmap_page_protect(..., UVM_PROT_NONE), and we
need to use that "combined_pte" to return true if any of the bits
we've been asked to clear were set (previously we only returned
true if we actually cleared one from a mapping's PTE, which,
as previously noted, might all be gone by this point).
The symptom here would be random crashes under memory pressure,
things like spurious NULL-derefs, indicative of an anonymous
page being tossed under memory pressure and re-ZFOD'd, rather
than being sent to swap and properly paged back in.
Pull up following revision(s) (requested by isaki in ticket #1264):
sys/arch/x68k/x68k/disksubr.c: revision 1.38
usr.sbin/sysinst/arch/x68k/md.c: revision 1.14
sysinst/x68k: Remove unnecessary conditions in md_disklabe_is_default().
lp->d_bbsize and lp->d_sbsize should be constants (this is probably another
bug) and should not be part of this check.
Fix PR install/59600
x68k: Initialize d_bbsize and d_sbsize on the disklabel always.
These values are for (old) FFS, so it didn't make sense to initialize
only when the BSD disklabel was missing and the Human68k partition existed.
This avoids disklabel(8)'s warnings:
disklabel: boot block size 0
disklabel: super block size 0
Inspired from PR install/59600.
Pull up following revision(s) (requested by isaki in ticket #265):
sys/arch/x68k/x68k/disksubr.c: revision 1.38
usr.sbin/sysinst/arch/x68k/md.c: revision 1.14
sysinst/x68k: Remove unnecessary conditions in md_disklabe_is_default().
lp->d_bbsize and lp->d_sbsize should be constants (this is probably another
bug) and should not be part of this check.
Fix PR install/59600
x68k: Initialize d_bbsize and d_sbsize on the disklabel always.
These values are for (old) FFS, so it didn't make sense to initialize
only when the BSD disklabel was missing and the Human68k partition existed.
This avoids disklabel(8)'s warnings:
disklabel: boot block size 0
disklabel: super block size 0
Inspired from PR install/59600.
[MSP430] Compute c+1 at the operand bit width in EmitCMP (#195892)
EmitCMP folds `c CMP rhs` into `rhs CMP' c+1` for four condition codes.
The `c+1` must wrap modulo the i16 operand width, but the current code
does `DAG.getConstant(C->getSExtValue() + 1, dl, MVT::i16)`:
sign-extending to `int64_t`, adding there, then handing the result to
the unsigned
`getConstant(uint64_t, ..., MVT::i16)` overload.
For constants with bit 15 set the negative `int64_t` is reinterpreted as
a huge `uint64_t`, which
trips the `isUIntN(16, val)` assertion in the APInt constructor under
`LLVM_ENABLE_ASSERTIONS` and yields an APInt with non-zero bits past its
declared width otherwise.
Switching to `DAG.getSignedConstant(C->getSExtValue() + 1, ...)` routes
through the signed `APInt` constructor, which checks `isIntN(16, val)`
and accepts the negative `c+1` produced when the high bit is set. The
four EmitCMP fold branches (SETUGE, SETULT, SETGE, SETLT) are updated
identically.
[AMDGPU] Cost of i8 vector insert/extract is free in some cases (#194991)
Reduce the cost of i8 vector insert and extract elements to avoid
scalarization in VectorCombine.
It is impossible to know during VectorCombine if an extract element will
require additional instructions or be free. There is a lot of additional context
needed to make that assessment. For example, what instructions are using
the extract elements or what other extract element index values occur. This
patch chooses some cases that likely do not require instructions, which
reduces the overall cost and avoids scalarization. Because of this chance, there
are SLP vectorization opportunities that are missed. In general, those missed
SLP vectorization cases require scalarization during code generation, and the
compiler ends up generating the same code with and without SLP vectorization.
nuageninit: modify the test to show the issue fixed inc316ec259011
Ensure the script used is invalid when parsed by libyaml which
highlight the issue revealed in PR295062
while at here validate the mode of the file is properly changed
PR: 295062
MFC After: 1 day
(cherry picked from commit 2a86992ab5019b4997ccadf7427011ba44e33c97)
nuageinit: only parse user_data as yaml when necessary
This fixes a regression introduced in cae280931c9e which prevents
user_data as a shell script to be used
PR: 295062
Reported by: Ross McKelvie <ross at exitzero.uk>
MFC After: 1 day
(cherry picked from commit c316ec259011e9e22e40eaa72d834f3bfac95c28)
Pull up following revision(s) (requested by riastradh in ticket #264):
sys/dev/nvmm/x86/nvmm_x86_svm.c: revision 1.94
sys/dev/nvmm/x86/nvmm_x86_vmx.c: revision 1.94
nvmm: Don't report physical lapic freq as virtual lapic freq.
The virtual lapic emulated by qemu in software always ticks at 1 GHz,
but the physical lapic on my laptop, for example, ticks at 24 MHz.
In order for this to work as iMil intended, we need some way for the
hypervisor (such as qemu) to tell nvmm what its lapic frequency is.
Until we have that, we can't correctly report any alleged lapic
frequency to the guest.
PR kern/59424: hardclock ticks run at breakneck pace under qemu
nuageinit: only parse user_data as yaml when necessary
This fixes a regression introduced in cae280931c9e which prevents
user_data as a shell script to be used
PR: 295062
Reported by: Ross McKelvie <ross at exitzero.uk>
MFC After: 1 day
(cherry picked from commit c316ec259011e9e22e40eaa72d834f3bfac95c28)
nuageninit: modify the test to show the issue fixed inc316ec259011
Ensure the script used is invalid when parsed by libyaml which
highlight the issue revealed in PR295062
while at here validate the mode of the file is properly changed
PR: 295062
MFC After: 1 day
(cherry picked from commit 2a86992ab5019b4997ccadf7427011ba44e33c97)
[cmake] Forward MacOS sysroot to runtimes when not crosscompiling (#182501)
The LLVM build documentation says that setting CMAKE_OSX_SYSROOT should
be sufficient to correctly configure the sysroot, however this flag was
not forwarded to the build of runtimes: leading to failures in flang-rt
tests. https://llvm.org/docs/CMake.html#apple-osx
It is not safe to forward this flag in general because the runtime might
be cross-compiled. In this case I have tried to do this only for native
builds. My intention here is not to make the build more complex than
currently documented.
Pull up following revision(s) (requested by andvar in ticket #2011):
sys/dev/pci/ahcisata_pci.c: revision 1.73
ahcisata(4): disable NCQ for VIA VT8251 integrated SATA controller.
NCQ support is known to be non-compliant or broken on this chipset,
causing timeouts and instability.
The issue is reproducible in NetBSD using 'smartctl -a`.
The workaround is to disable NCQ, which has already been done in other
OS drivers.
Pull up following revision(s) (requested by andvar in ticket #1263):
sys/dev/pci/ahcisata_pci.c: revision 1.73
ahcisata(4): disable NCQ for VIA VT8251 integrated SATA controller.
NCQ support is known to be non-compliant or broken on this chipset,
causing timeouts and instability.
The issue is reproducible in NetBSD using 'smartctl -a`.
The workaround is to disable NCQ, which has already been done in other
OS drivers.
Pull up following revision(s) (requested by andvar in ticket #263):
sys/dev/pci/ahcisata_pci.c: revision 1.73
ahcisata(4): disable NCQ for VIA VT8251 integrated SATA controller.
NCQ support is known to be non-compliant or broken on this chipset,
causing timeouts and instability.
The issue is reproducible in NetBSD using 'smartctl -a`.
The workaround is to disable NCQ, which has already been done in other
OS drivers.
[AArch64][llvm] Add missing form for `LD64B`/`ST64B` instructions (#196301)
`LD64B` and `ST64B` are defined as follows[1]:
```
LD64B <Xt>, [<Xn|SP> {,#0}]
```
but they're missing the form that allows a zero immediate offset,
for example:
```
ld64b x2, [x13, #0]
st64b x16, [x13, #0]
```
Add support for zero immediate offsets for these instructions.
[1] https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/LD64B--Single-copy-Atomic-64-byte-Load-
