Targets: Remove redundant TRI arguments from InstrInfo helpers
This is directly available in TargetInstrInfo.
Co-authored-by: Claude Opus 5 <noreply at anthropic.com>
CodeGen: Remove TRI arguments from TargetInstrInfo hooks
TRI can now always directly be referenced from TargetInstrInfo
Co-authored-by: Claude Opus 5 <noreply at anthropic.com>
[CIR] Convert null pointer constant types in target lowering (#228068)
The pass converted the cir.const result type but not the type inside its
`#cir.ptr` attribute, so the verifier rejected address-space null
constants
Reland [AArch64][CostModel] Consider some nxv1 operations as legal (#214471) (#228371)
This is allowing some operations on vscale x 1 types, namely:
- load/store
- masked load/store
- arithmetic instructions like add/sub/mul
For those, there is already codegen coverage. See e.g.
- llvm/test/CodeGen/AArch64/sve-int-arith.ll
- llvm/test/CodeGen/AArch64/sve-load-store-legalisation.ll
- llvm/test/CodeGen/AArch64/sve-masked-gather.ll
- llvm/test/CodeGen/AArch64/sve-masked-scatter.ll
These types are relevant for enabling REVEC in LoopVectorizer. For
AArch64, the main target there is turning NEON vector sizes into SVE
vector size, i.e. using VF = "vscale x 1". For loops with mixed vector
and scalar types, we'll want to allow vectorising scalar types with such
a VF.
[2 lines not shown]
[lldb][Windows] Report a process exit once the process is gone (#228115)
When a debugged process exits, lldb and lldb-server report the exit
while Windows is still tearing the process down. Its executable and DLLs
are still loaded at that point, so a test that deletes or replaces one
of them right after the exit fails with `"access denied"`. This is what
makes `TestReplaceDLL` fail on Windows CI.
This patch reports the exit only after the debugger has released the
exit event and the process has fully terminated, which matches how POSIX
reports an exit.
On a Windows 11 host, `TestReplaceDLL` fails to delete `foo.dll` in 246
out of 640 runs before the change and in 0 of 1,600 after.
rdar://188918066
NAS-144144 / 27.0.0 / Fix network.common.check_dhcp_or_aliases never rejecting unconfigured interfaces (by Qubad786) (#19909)
## Problem
The check passed a list of each interface's settings to `any()`, and a
non-empty list is always truthy, so `interface.commit` only failed when
there were no interfaces at all. Committing a config where no interface
had DHCP, IPv6 autoconfig or an address would go through and `sync()`
would unconfigure every NIC.
## Solution
Check each interface's IPv4 DHCP, IPv6 autoconfig and aliases directly,
failing only when none of them is configured.
Original PR: https://github.com/truenas/middleware/pull/19898
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-144144 / 28.0.0-BETA.1 / Fix network.common.check_dhcp_or_aliases never rejecting unconfigured interfaces (#19898)
## Problem
The check passed a list of each interface's settings to `any()`, and a
non-empty list is always truthy, so `interface.commit` only failed when
there were no interfaces at all. Committing a config where no interface
had DHCP, IPv6 autoconfig or an address would go through and `sync()`
would unconfigure every NIC.
## Solution
Check each interface's IPv4 DHCP, IPv6 autoconfig and aliases directly,
failing only when none of them is configured.
NAS-144158 / 27.0.0 / Read NVDIMM health from the kernel instead of running ixnvdimm (by yocalebo) (#19908)
The NVDIMM alert check ran the ixnvdimm program twice for every module.
That made 24 firmware requests per module every five minutes. The check
used the results of only seven of them. Any of those requests can fail
when kernel memory is fragmented. The check now asks the kernel directly
through a new helper in utils/hardware/nvdimm.py. It makes three
requests per module on each check. Values that only change on reboot are
read once and kept. A failed request is tried one more time. If it fails
again the check keeps the alerts it already has. The three warning
threshold names now each use their own bit. ixnvdimm tested the lowest
bit for all of them.
Original PR: https://github.com/truenas/middleware/pull/19905
Co-authored-by: Caleb St. John <30729806+yocalebo at users.noreply.github.com>
Bring the wireless interface up on first setup
On a fresh system wpa_supplicant has no saved network. driver_bsd
downs the interface while it initializes and only raises it again to
scan or associate, which it never does without an enabled network.
rc does not run ifconfig up on WPA interfaces either, so the card
stayed down and wpa_supplicant sat in INTERFACE_DISABLED, refusing
scan requests with FAIL-BUSY.
When setup-nic.py declares the wlan in rc.conf for the first time, it
now marks the interface up after pccard_ether starts it, so
wpa_supplicant sees the interface enabled and starts scanning.
[clang][OpenMP] Keep 'requires' directives read from an AST file (#220058)
An OpenMP `requires` directive is recorded in Sema when the directive is
parsed
(`SemaOpenMP::ActOnOpenMPRequiresDirective`). Nothing repopulated that
list from an AST
file. A translation unit that gets its `requires` directive from a PCH
or a module
therefore behaves as if the directive were absent, and clang rejects
valid code.
`OMPRequiresDecl` is already serialized and eagerly deserialized, so the
declaration is
present in the AST. Only Sema's view of it was missing.
## Reproducer
```c++
// rev.h
[60 lines not shown]
