[DAGCombiner] Narrow the integer source of uint_to_fp (#222899)
Truncate the source of a `uint_to_fp` when it is known to fit in a
narrower
type the target can convert from directly.
For example:
```
uitofp (and i64 %x, 255) to float
```
On AMDGPU this becomes a single `v_cvt_f32_ubyte0` instead of the
generic
i64 to f32 expansion.
Merge commit 681c2ee4dfbf from llvm-project (by Justin King):
asan: refactor interceptor allocation/deallocation functions (#145087)
Do some refactoring to allocation/deallocation interceptors. Expose
explicit per-alloc_type functions and stop accepting explicit AllocType.
This ensures we do not accidentally mix.
NOTE: This change rejects attempts to call `operator new(<some_size>,
static_cast<std::align_val_t>(0))`.
For https://github.com/llvm/llvm-project/issues/144435
Signed-off-by: Justin King <jcking at google.com>
This a prerequisite for adding sanitizer interceptors for free_sized(3)
and free_aligned_sized(3).
PR: 298943
MFC after: 1 week
Merge commit a5fa4dba6e2e from llvm-project (by PiJoules):
[compiler-rt] Add interceptors for free_[aligned_]sized for asan+hwasan (#189109)
This avoids a jemalloc assertion when running sanitized applications
against glib, which uses free_sized(3).
PR: 298943
MFC after: 1 week
compiler-rt: enable use of .preinit_array after ef758b59a44e
After base ef758b59a44e6b5b2d2dc178b97c01cde1b34570 we can enable usage
of .preinit_array in compiler-rt's sanitizers. The comment that stated
"On FreeBSD, .preinit_array functions are called with rtld_bind_lock
writer lock held. It will lead to dead lock ..." can also be removed.
PR: 298943
MFC after: 1 week
The list of ignored environment variables and the conditions under
which they are ignored or removed from downstream environment has
become too complicated to list at every specific variable, so replace
all of them a single note at the end which also mentions the new
restriction for binary readability.
[RuntimeDyld] Fix layout-dependent REL16 checks in `ppc32_elf_reloc.s` (#230861)
`ppc32_elf_reloc.s`, introduced in #229933, fails on Windows.
```
Expression 'decode_operand(rel16_lo, 2) = (object - rel16_ha) [15:0]' is false: 0xfffffffffffffff4 != 0xfff4
```
`decode_operand` sign-extends the left side, so `0xfff4` becomes
`0xfffffffffffffff4`. The slice on the right-hand side stays `0xfff4`
and the test fails.
The fix is to slice the left side:
```diff
# R_PPC_REL16_HA and R_PPC_REL16_LO
-# rtdyld-check: decode_operand(rel16_ha, 2) = (object - rel16_ha + 0x8000) [31:16]
+# rtdyld-check: decode_operand(rel16_ha, 2)[15:0] = (object - rel16_ha + 0x8000)[31:16]
rel16_ha:
[9 lines not shown]
VE: Remove broken nested call frame around dynamic stack allocation
lowerDYNAMIC_STACKALLOC wrapped the __ve_grow_stack call and the
GETSTACKTOP stack-pointer read in a zero-sized CALLSEQ_START/CALLSEQ_END
pair. The call it contains emits its own CALLSEQ, so the outer bracket
only produced a nested ADJCALLSTACKDOWN 0 / ADJCALLSTACKUP 0 around the
inner ADJCALLSTACKDOWN / ADJCALLSTACKUP which is illegal.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
If AUX_openbsd_execmode lacks S_IRUSR, disable a plethora of LD_*
environment variables which emit information about the binary at
startup. Some of these are minor info leaks, like the exec address of
the binary and shared library locations. For binaries which are unreadable,
we should respect the wishes of whoever set the mode restrictively.
I made a few more relinked binaries non-readable, and dgl pointed out
that ld.so was leaking too much information so this is the fix.
AUX_openbsd_execmode's au_v provides a mode_t containing S_ISUID and
S_ISGUID from the executable file's mode_t, and S_IRUSR which says
whether the executable file was openable for read-access (with the
process' uid/gids and the file's mode_t permissions).
ok kettenis and others
