[SelectionDAG] Fix null pointer dereference in resolveDanglingDebugInfo (#180425)
Fix crash when Val.getNode() is null by moving ValSDNodeOrder
declaration inside the null check.
The crash occurred when compiling code with debug info containing
aggregate types with nested empty structs.
[AArch64][PAC] Mark $Scratch operand of AUTxMxN as earlyclobber (#173999)
This fixes an assertions when emitting code at `-O0`.
(cherry picked from commit a47f3802bfd7f8f4c56cb11bad89d844398e6662)
clang/AMDGPU: Stop checking for finite only and unsafe math control libraries
These will be imminently deleted. Just ignore them if they are not present.
Add records about new ports committer (nxjoseph)
New author entry for Yusuf Yaman together with the news item and PGP
key added. List of Developers and Contributors updated as well to follow
steps 1-4 of the Committers Guide.
Reviewed by: osa, vvd (mentors)
Approved by: osa, vvd (mentors)
Differential Revision: https://reviews.freebsd.org/D55435
[NFC][AMDGPU] Add test showing caller/callee SGPR mismatch for inreg args
Add a test demonstrating a bug where the caller and callee disagree on which
SGPRs hold user inreg arguments when there are enough to reach the SGPR0-3
range.
On the callee side, `LowerFormalArguments` marks SGPR0-3 as allocated in
`CCState` before the CC analysis runs. On the caller side, `LowerCall` adds the
scratch resource to `RegsToPass` without marking SGPR0-3 in `CCState`. This
causes `CC_AMDGPU_Func` to assign user inreg args to SGPR0-3 on the caller side
(they appear free) while the callee skips them.
In the test, the caller writes arg 0 (value 42) to s0, but the callee reads arg
0 from s16.
[NFC][AMDGPU] Add test showing caller/callee SGPR mismatch for inreg args
Add a test demonstrating a bug where the caller and callee disagree on which
SGPRs hold user inreg arguments when there are enough to reach the SGPR0-3
range.
On the callee side, `LowerFormalArguments` marks SGPR0-3 as allocated in
`CCState` before the CC analysis runs. On the caller side, `LowerCall` adds the
scratch resource to `RegsToPass` without marking SGPR0-3 in `CCState`. This
causes `CC_AMDGPU_Func` to assign user inreg args to SGPR0-3 on the caller side
(they appear free) while the callee skips them.
In the test, the caller writes arg 0 (value 42) to s0, but the callee reads arg
0 from s16.
[AArch64][clang][llvm] Add ACLE `stshh` atomic store builtin
Add `__arm_atomic_store_with_stshh` implementation as defined
in the ACLE. Validate that the arguments passed are correct, and
lower it to the stshh intrinsic plus an atomic store with the
allowed orderings.
Gate this on FEAT_PCDPHINT so that availability matches
hardware support for the `STSHH` instruction. Use an i64
immediate and side-effect modeling to satisfy tablegen and decoding.
clang/AMDGPU: Stop checking for finite only and unsafe math control libraries
These will be imminently deleted. Just ignore them if they are not present.
NAS-139938 / 25.10.2.1 / Fix ClientConnectorCertificateError object has no attribute _os_error (by themylogin) (#18275)
Automatic cherry-pick failed. Please resolve conflicts by running:
git reset --hard HEAD~1
git cherry-pick -x d9a40f93a083c538cdc1dac8f26437fec6a654ac
If the original PR was merged via a squash, you can just cherry-pick the
squashed commit:
git reset --hard HEAD~1
git cherry-pick -x 5966611429782bc7b9b295664a15441406c1147c
Original PR: https://github.com/truenas/middleware/pull/18274
Co-authored-by: themylogin <themylogin at gmail.com>
[clang][layout] Fix unsigned char overflow in ms_struct bitfield layout (#181433)
Fixes #161511
When using MS-struct layout rules (`#pragma ms_struct`), Clang produces
incorrect memory layouts when encountering large `_BitInt` bit-fields.
The reason was that `LastBitfieldStorageUnitSize` variable was declared
as `unsigned char`, which caused it to overflow when the values used
with `_BitInt` exceeded `255`, so I changed it from `unsigned char` to
`uint64_t`.
In the added test, we can clearly see that `f2` and `f3` are both packed
in the same 256-bit unit.
[NFC][AMDGPU] Add test showing caller/callee SGPR mismatch for inreg args
Add a test demonstrating a bug where the caller and callee disagree on which
SGPRs hold user inreg arguments when there are enough to reach the SGPR0-3
range.
On the callee side, `LowerFormalArguments` marks SGPR0-3 as allocated in
`CCState` before the CC analysis runs. On the caller side, `LowerCall` adds the
scratch resource to `RegsToPass` without marking SGPR0-3 in `CCState`. This
causes `CC_AMDGPU_Func` to assign user inreg args to SGPR0-3 on the caller side
(they appear free) while the callee skips them.
In the test, the caller writes arg 0 (value 42) to s0, but the callee reads arg
0 from s16.
