[libc] Fix BigInt shift on big-endian platforms (#196957)
BigInt<128> stores the value in two separate word sized array slots
with the low 64 bits being stored in val[0] and high 64 bits in val[1].
This can't be reinterpreted as a 128 bit value on big-endian platforms
because the values are reversed.
This has caused test failures on s390x builds of V8:
https://issues.chromium.org/issues/511831894
---------
Co-authored-by: Guillaume Chatelet <gchatelet at google.com>
[flang][FIRToMemRef] [flang][fir-to-memref] Lower complex projected slices via memref<...x2xT> reinterpretation (#196123)
At the `fir.array_coor` site, reinterpret the
`memref<d0×...×complex<T>>` as `memref<d0×...×2×T>` via `fir.convert`,
then append the component index (0=re, 1=im) as the final memref index.
Loads and stores then operate directly on a scalar `T`-sized location.
[lldb] Handle SIGINT via the MainLoop signal thread (on POSIX) (#196687)
The driver's async SIGINT handler called
SBDebugger::DispatchInputInterrupt directly. That is not
async-signal-safe and can lead to a crash.
Register SIGINT with the existing signal-thread MainLoop instead so
DispatchInputInterrupt runs in normal thread context. The Windows path
is unchanged and keeps the legacy async handler.
While DispatchInputInterrupt runs, the callback temporarily installs
SIG_DFL so a second Ctrl-C still hard-terminates the process, preserving
the escape hatch users rely on when the debugger is unresponsive.
Moving SIGINT off the main thread means a Ctrl-C no longer interrupts
blocking syscalls there (e.g. a Python REPL waiting on input or
sleeping), so Python never observes the queued interrupt and
KeyboardInterrupt is not raised. To restore that behavior, after
dispatching the interrupt the callback re-raises SIGINT on the main
[6 lines not shown]
[clang] Forward `-fvalidate-ast-input-files-content` when loading AST dumps
`-fvalidate-ast-input-files-content` is silently ignored when loading
PCH files for additional translation units.
This triggers an import failure when modification time of some of input
files changes (for example, the AST dump is being reused for a
subsequent cross-translation-unit re-analysis with Clang Static Analyzer
after a fresh code checkout).
This makes it difficult to use cached AST dumps.
This patch enables the user to control validation of AST input files,
without imposing it on them.
--
CPP-8312, CPP-8025
[SPIR-V] Add support for OpFMod intrinsic (#193172)
Add the `spv.fmod` intrinsic and lower it directly to `SPIRV::OpFMod`
covering scalar and vector cases
[SelectionDAG] Drop unnecessary lower bound check in `lowerRangeToAssertZExt` (#196785)
Drop the `Lo.isMinValue()` check in `lowerRangeToAssertZExt`.
The check was introduced in 2bba779272a2 when the bit width was computed
via `logBase2(Hi)`, which required `Lo == 0` for correctness. It is no
longer needed since 9e04befb0979 when we switched to
`getUnsignedMax().getActiveBits()` for bit width.
The change in `DAGCombiner.cpp` is to prevent a regression in
`llvm/test/CodeGen/AMDGPU/llvm.amdgcn.wavefrontsize.ll`. I wasn't able
to construct an individual test for it.
---------
Co-authored-by: nikic <github at npopov.com>
[DAGCombiner] Fix abs(add) to abdu miscompile in foldABSToABD (#196782)
The abs(add(x, y)) → abdu(x, -y) fold added in #186659 is incorrect when
both operands are known non-negative and their sum does not overflow
signed.
When both x and y are non-negative and `x + y < 2^31`, `abs(x + y) = x +
y`, but `abdu(x, -y) = 2^32 - y - x ≠ x + y`.
For example, `abs(add(0, 1)) = 1`, but `abdu(0, -1) = 0xFFFFFFFF`.
Related: #185467 #175801
[PM] Make InvalidateAllAnalysesPass Optional (#196956)
Similar reasoning to 221a24e94f7b03ea881df34cc8867c58ac8fdb52. Making
this required means we end up with assertion failures in the LPM around
LCSSA.
This is a bit unfortunate given it would be nice to ensure we can
trivially invalidate analyses on optnone functions, but this matches the
old behavior and prevents and assertion failure for now.
