DAG: Replace legal type check in EmitCopyFromReg (#177788)
It doesn't make sense that an illegal type would get here; a
CopyFromReg cannot be illegally typed. The only exception that
was hit here is in a handful of SystemZ inline assembly tests
for i128, which use untyped. They shouldn't; it should treat
v2i64 as legal instead. Just leave the untyped check for now.
[libc++] Remove `__wrap_iter::base()` (#179389)
Resolves #126442
- Converts all the relevant functions that used `.base()` into friends
- Fixed usage in `<regex>`
---------
Co-authored-by: A. Jiang <de34 at live.cn>
Add remove_scfb and remove_vesa and refactor cleanup functions
Add remove_scfb() and remove_vesa() to uninstall xf86-video-scfb and
xf86-video-vesa when a proper driver is configured. Call them in
cmd_auto() for all GPU and VM detections, except hyperv and bhyve which
use the scfb driver internally.
Rename all cleanup_* functions to remove_* and drop template file
deletion, limiting them to package removal only. Remove cleanup_hyperv
and cleanup_bhyve as they had no packages to remove.
[mlir][sparse] Fix crash in sparsification when unary/binary present block captures sparse tensor argument (#184597)
`relinkBranch` in Sparsification.cpp assumed that any block argument
from the outer `linalg.generic` op encountered inside an inlined
semi-ring branch must be a dense tensor, and asserted accordingly.
However, the `present` block of a `sparse_tensor.unary` (or similar
semi-ring ops) is permitted to capture sparse tensor operands directly
via `isAdmissibleBranchExp`, which accepts any `BlockArgument` as
admissible.
The fix removes the incorrect assertion and extends the load generation
to handle sparse tensors using `genSubscript`, which already knows how
to return the value buffer and current value position via the loop
emitter. The `kSparseIterator` strategy (where `genSubscript` returns a
`TensorType`) is also handled by emitting a
`sparse_tensor.extract_value` op.
Fixes #91183
Reapply "[SPIRV] Emit intrinsics for globals only in function that references them (#178143 (#179268)) (#182552)
This reverts commit 395858d9f172ff1c61c661aa7c2a18b449daffa6.
This PR had been reverted due to an unrelated address-sanitizer failure.
[mlir][sparse] Fix crash in SparseAssembler when run after SparseTensorCodegen (#183896)
After --sparse-tensor-codegen, sparse tensor arguments are replaced by
memrefs and \!sparse_tensor.storage_specifier types. The subsequent
--sparse-assembler pass calls getSparseTensorEncoding() to identify
sparse arguments to wrap/unwrap. However, getSparseTensorEncoding()
returns non-null for StorageSpecifierType as well as for sparse
RankedTensorType. Since StorageSpecifierType is not a RankedTensorType,
the subsequent cast<RankedTensorType> in convTypes() and convVals()
would crash with an assertion failure.
Fix by also checking isa<RankedTensorType>(type) in the passthrough
condition in both convTypes() and convVals(), so that
StorageSpecifierType arguments pass through unchanged.
Fixes #183776
[HLSL] Amend f32tof16() and f16tof32() tests (#179261)
Amend the codegen tests for f32tof16() and f16tof32() to include SPIRV
as a target in addition to DXIL.
Fixes #179257
Co-authored-by: Tim Corringham <tcorring at amd.com>
vnet: Ensure the space allocated by vnet_data_alloc() is sufficent aligned
Some 32-bit architectures, e.g., armv7, require strict 8-byte
alignment while doing atomic 64-bit access. Hence aligning to the
pointer type (4-byte alignment) does not meet the requirement on
those architectures.
Make the space allocated by vnet_data_alloc() sufficent aligned to
avoid unaligned access.
PR: 265639
Diagnosed by: markj
Reviewed by: jhb, markj
Co-authored-by: jhb
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55560
(cherry picked from commit 32beb3ae71cb320dbe4190a01c036943d99083b3)
(cherry picked from commit 973d607b284ba68e63f0386af44c28bfde15add2)
(cherry picked from commit baee504b868b9417c815c0de6474a0d6e5d6b4ac)
Downgrade maybe-uninitialized to a warning for grid.c
Otherwise aarch64 builds fail with:
/home/source/ab/netbsd-10/src/external/bsd/tmux/dist/grid.c: In function 'grid_string_cells':
/home/source/ab/netbsd-10/src/external/bsd/tmux/dist/grid.c:1070:22: error: 'size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
1070 | size_t len, off, size, codelen;
| ^~~~
but the code always initializes size before first use.
Firewall: Rules [new]: Fix category colors in grid
Before this change, the controller returned color values and the frontend matched them best effort to the category key. This means there was an implicit order, and this order could break.
With this change, order independant metadata is returned, and the frontend renders these categories directly in the category formatter.
[lldb][test] TestDataFormatterGenericOptional.py: remove obsolete skipIfs
Clang 7 and GCC 5 are pretty ancient. There's unlikely to be any bot configurations running this anymore. Lets remove it to reduce test noise.
[lldb][test] Clean up USE_LIBSTDCPP/USE_LIBCPP usage
This patch makes the two tests consistent with the rest of the formatter API tests (and is in my opionion easier to follow).
[Flang] Fix wrong compile-time error message, issue #178494. (#183878)
Fix the problem described in issue #178494. It will cover the failures
with S, SP, SS, BN, BZ, LZ, LZP, LZS, etc. It will resolve the test
failures in PR #183500.
vnet: Ensure the space allocated by vnet_data_alloc() is sufficent aligned
Some 32-bit architectures, e.g., armv7, require strict 8-byte
alignment while doing atomic 64-bit access. Hence aligning to the
pointer type (4-byte alignment) does not meet the requirement on
those architectures.
Make the space allocated by vnet_data_alloc() sufficent aligned to
avoid unaligned access.
PR: 265639
Diagnosed by: markj
Reviewed by: jhb, markj
Co-authored-by: jhb
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55560
(cherry picked from commit 32beb3ae71cb320dbe4190a01c036943d99083b3)
(cherry picked from commit 973d607b284ba68e63f0386af44c28bfde15add2)
