[AMDGPU] Minor cleanups in offload plugin and AMDGPUEmitPrintf. NFC. (#187587)
Use empty() in assert, brace-init instead of std::make_pair in the
AMDGPU offload plugin, and fix a comment typo in AMDGPUEmitPrintf.
[CIR] Upstream CUDA mangling test with LLVM and OGCG verification (#184444)
This PR upstreams the `mangling.cu` test from the ClangIR incubator.
Building on the feedback from my previous upstreaming PR, I have
expanded the verification for this file to include:
1. **CIR checks:** Verifying the ClangIR generated functions.
2. **LLVM checks:** Verifying the LLVM IR generated via the ClangIR
pipeline.
3. **OGCG checks:** Verifying against the original CodeGen pipeline to
ensure name-mangling parity.
I have also moved the `Inputs/cuda.h` mock header to the upstream
`Inputs` directory to support this and future CUDA tests.
If this multi-stage verification approach looks correct to the
maintainers, I plan to follow up by upstreaming the other currently
passing CUDA test, `simple-nvptx-triple.cu`, using the same standard.
Verified locally with `llvm-lit`. Partially addresses #156747.
Add CI test for PR state preservation across HA failover
Two initiators register keys and one holds a WRITE EXCLUSIVE reservation.
The system is failed over twice (failback included) and after each failover
both keys and the reservation are verified on both paths.
ahc: Fix support for multi-channel PCI controllers.
Some old EISA controllers driven by ahc had two channels on one
controller (aka "TWIN" channels), while all later PCI models
supporting multiple channels did so by having multiple controllers
in one PCI device, each being a separate PCI function.
The ahc interrupt handler wrongly assumed that anything but channel
'A' is always the 2nd channel of a TWIN channel controller, passing
sc_channel_b to scsipi_channel_{freeze,thaw}(). This of course is
wrong for multi-channel PCI ahc controllers, leading to a immediate
panic when there's anything connected to any channel but 'A'.
editors/vim: Update to 9.2.0204 (security fix)
In particular, this addresses the following:
Problem: The glob() function on Unix-like systems does not escape
newline characters when expanding wildcards. A maliciously
crafted string containing '\n' can be used as a command
separator to execute arbitrary shell commands via
mch_expand_wildcards(). This depends on the user's 'shell'
setting.
Solution: Add the newline character ('\n') to the SHELL_SPECIAL
definition to ensure it is properly escaped before being
passed to the shell (pyllyukko).
Security: GHSA-w5jw-f54h-x46c
(cherry picked from commit a215214dc5d94d8906ebddd92640062e91b0fd7b)
editors/vim: Update to 9.2.0204 (security fix)
In particular, this addresses the following:
Problem: The glob() function on Unix-like systems does not escape
newline characters when expanding wildcards. A maliciously
crafted string containing '\n' can be used as a command
separator to execute arbitrary shell commands via
mch_expand_wildcards(). This depends on the user's 'shell'
setting.
Solution: Add the newline character ('\n') to the SHELL_SPECIAL
definition to ensure it is properly escaped before being
passed to the shell (pyllyukko).
Security: GHSA-w5jw-f54h-x46c
[Clang][AMDGPU] Minor driver cleanups. NFC. (#187586)
Use empty() instead of size() checks, back() instead of [size()-1], and
brace-init instead of std::make_pair in the AMDGPU and HIP driver
toolchains.
[libc] Modular printf option (float only) (#147426)
This adds LIBC_CONF_PRINTF_MODULAR, which causes floating point support
(later, others) to be weakly linked into the implementation.
__printf_modular becomes the main entry point of the implementaiton, an
printf itself wraps __printf_modular. printf it also contains a
BFD_RELOC_NONE relocation to bring in the float aspect.
See issue #146159 for context.
17887 loader.efi: panic() should show stack trace
Reviewed by: Jason King <jason.brian.king+illumos at gmail.com>
Approved by: Dan McDonald <danmcd at edgecast.io>
[NFC] Annotate CommentFlag with underlying type (#186560)
This is stored in `uint8_t AsmPrinterFlags`, and `setAsmPrinterFlag` was
already using `uint8_t` in the API. This change doesn't use a scoped
enum as targets extend this enum by starting their enums with the
`TAsmComments` value.
This also introduces a typedef for the uint8_t for documentation purposes.
[lldb][TypeSystem] Add CompilerType::IsMemberDataPointerType (#187172)
**Description:**
Adds `IsMemberDataPointerType()` to CompilerType / TypeSystem /
TypeSystemClang, mirroring the existing `IsMemberFunctionPointerType()`.
LLDB already has `IsMemberFunctionPointerType()` to identify member
function pointers but no counterpart for member data pointers. The only
way to check for member data pointers was the indirect `GetTypeClass()
== eTypeClassMemberPointer && !IsMemberFunctionPointerType()`, which is
awkward.
This pr is split out from a larger [fix,
186629](https://github.com/llvm/llvm-project/pull/186629) for LLDB
mishandling non-type template parameters (NTTPs) of pointer-to-member
types, where cleanly distinguishing member data pointers from member
function pointers is needed. The new API delegates to clang's
`QualType::isMemberDataPointerType()` via the same I`sTypeImpl` pattern
[12 lines not shown]
[AMDGPU] Fix setreg handling in the VGPR MSB lowering
There are multiple issues with it:
1. It can skip inserting S_SET_VGPR_MSB if we set the mode via
piggybacking. We are now relying on the HW bug for correct
behavior. If/when the bug is fixed lowering will be incorrect.
2. We should just unconditionally update MSBs if immediate allows it.
We shall set correct bits and keep the rest of the immediate
(that is done). There is no reasonable way for an user to change
MSBs nor does it do anything good to set it with SETREG and then
immediately overwrite with S_SET_VGPR_MSB.
3. We can always update immediate if Offset is zero.
4. Redundant mode changes created as seen in the
hazard-setreg-vgpr-msb-gfx1250.mir.
5. Decoding of the immediate was also wrong with non-zero offset
and did not factor MSB fixup offset handling.
With unconditional immediate update most of time and not relying on
[12 lines not shown]
[DirectX] Fix TypedBuffer load shader flag mismatch (#187393)
Fixes #187225.
The `TypedUAVLoadAdditionalFormats` shader flag was being set for all
TypedBuffer vector loads, so loading from a `Buffer<int64_t2>` was
incorrectly triggering this flag and causing the mismatch. This PR
changes it so the flag is only set for UAV loads.