[DAG] visitIS_FPCLASS - fold to constant when result is fully determined by KnownFPClass (#193737)
This PR teaches `DAGCombiner::visitIS_FPCLASS` to fold directly to
constant `true` based on the source's `KnownFPClass`, instead of only
narrowing the test mask.
Prep work to help with https://github.com/llvm/llvm-project/pull/193672
[AArch64][llvm] Remove support for FEAT_MPAMv2_VID (#193191)
`FEAT_MPAMv2_VID` instructions and system registers, as introduced
in change d30f18d2c, are being removed at this time, as they've been
removed from the latest Arm ARM, which doesn't preclude them returning
in some form in future.
Other system registers introduced with `FEAT_MPAMv2` are unaffected,
and these continue to be ungated, but since `+mpamv2` gating is now
empty,
I'm removing this superfluous gating code.
[Clang][Sema] Change `ExtnameUndeclaredIdentifiers` to MapVector. (#193924)
Iteration order of this map does not matter for compilation, except that
since 475f71e8fa15ee71f99e450a0e1c90d3961005f9, this data is dumped into
precompiled header files and thus affects content of those files.
To make precompiled header file contents deterministic, changing its
type to one that has deterministic iteration order, matching the nearby
`WeakUndeclaredIdentifiers`.
Fixes #193923
[X86] masked div/rem tests - fix avx512 and add sse4/avx2 test coverage (#193933)
Noticed the incorrect "-mattr=+avx512" attribute, and replaced it with proper x86-64-v* level test coverage
Reland "[lldb][Linux] Read memory protection keys for memory regions (#193934)" (#193936)
This reverts commit 390a29ea833965f481a7011b07deed9612229d6e.
Two tests failed on the X86 buildbot but not in GitHub CI because the
buildbot has protection keys and the CI machines do not. I ran the tests
on an AArch64 host without protection keys, and only selected tests on a
simulated AArch64 machine with protection keys, so I did not find this
earlier.
The fix was to add "protection-key" to the list of possible
qMemoryRegionInfo response keys.
[clang][bytecode] Fix `MemberExpr`s with a static member (#193902)
We need logic to load from the reference pointer, similar to the one we
have for regular `DeclRefExpr`s.
[AAEval] Print ModRefInfo for atomic operations (#193935)
Print ModRefInfo for fence, atomicrmw, etc. Also for atomic
load and store, as these may have additional effects beyond
what is implied by the simple alias result.
[LangRef] Specify that syncscopes can affect the monotonic modification order
If a target specifies that atomics with mismatching syncscopes appear
non-atomic to each other, there is no point in requiring them to be ordered in
the monotonic modification order. Notably, the [AMDGPU target user
guide](https://llvm.org/docs/AMDGPUUsage.html#memory-scopes) has specified
syncscopes to relax the modification order for years.
So far, I haven't found an example where this less constrained ordering would
be observable (at least with the AMDGPU inclusive scope rules). Whenever a load
would be able to see two monotonic stores with non-inclusive scope, that's
considered a data race (i.e., the load would return `undef`), so it cannot be
used to observe the order of the stores.
[AMDGPUUsage] Specify what one-as syncscopes do
This matches the currently implemented and (as far as I could determine)
intended semantics of these syncscopes.
The sync scope table is unchanged except for removing its indentation;
otherwise it would be rendered as part of the preceding note.
[LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race
Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.
For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:
```
; workgroup 0:
store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4
; workgroup 1:
store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```
[3 lines not shown]
[LangRef] Allow monotonic & seq_cst accesses to inter-operate with other accesses (#189014)
Currently, the LangRef says that atomic operations (which includes `unordered`
operations, which don't participate in the monotonic modification order) must
read a value from the modification order of monotonic operations.
In the following example, this means that the load does not have a store it
could read from, because all stores it may see do not participate in the
monotonic modification order:
```
; thread 0:
store atomic i32 1, ptr %p unordered, align 4
; thread 1:
store atomic i32 2, ptr %p unordered, align 4
load atomic i32, ptr %p unordered, align 4
```
[19 lines not shown]
py-simplejson: updated to 4.1.0
Version 4.1.0 released 2026-04-22
* The C extension now accelerates encoding when ``indent=`` is set.
Previously the encoder fell back to the pure-Python implementation
whenever a non-None ``indent`` was passed; now the C encoder emits
the newline-plus-indent prefix, the level-aware item separator, and
the closing indent directly. A representative nested-dict workload
benchmarks about 4-5x faster end-to-end, and the ``indent=0`` and
empty-container edge cases continue to match the Python output
byte-for-byte.
* The C extension now emits PEP 678 ``exc.add_note()`` annotations on
serialization failures, matching the pure-Python encoder. A chained
error on ``{'a': [1, object(), 3]}`` produces the same three notes
(``when serializing object object``, ``when serializing list item 1``,
``when serializing dict item 'a'``) whether the speedups are loaded
or not, so the add_note assertions in ``test_errors.py`` no longer
need ``indent=2`` to force the Python path.
py-scrapy: updated to 2.15.1
Scrapy 2.15.1 (2026-04-23)
Bug fixes
- Sharing of the SSL context between multiple connections, introduced in
Scrapy 2.15.0, is reverted as it caused problems and wasn't actually
needed.
- Fixed :meth:`scrapy.settings.BaseSettings.getwithbase` failing on keys with
dots that aren't import names. It now works the way it worked before Scrapy
2.15.0, without trying to match class objects and import path. A separate
method,
:func:`~scrapy.settings.BaseSettings.get_component_priority_dict_with_base`,
was added that does that, and it is now used for :ref:`component priority
dictionaries <component-priority-dictionaries>`.
- Documentation rendering improvements.
[lldb][Linux] Read memory protection keys for memory regions (#182246)
Memory protection keys
(https://docs.kernel.org/core-api/protection-keys.html) are implemented
using two things:
* A key value attached to each page table entry.
* A set of permissions stored somewhere else (in a register on AArch64
and X86), which is indexed into by that protection key.
So far I have updated LLDB to show the permissions part on AArch64 Linux
by reading the por register. Now I am adding the ability to see which
key each memory region is using.
```
(lldb) memory region --all
[0x0000000000000000-0x000aaaae3b140000) ---
[0x000aaaae3b140000-0x000aaaae3b150000) r-x /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out PT_LOAD[0]
protection key: 0
[0x000aaaae3b150000-0x000aaaae3b160000) rw- /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out
[27 lines not shown]
py-faker: updated to 40.15.0
40.15.0 - 2026-04-17
* Add job providers for `ar_DZ` and `fr_DZ` locales
* Add company providers for `ar_DZ` and `fr_DZ` locales
* Add geo providers for `ar_DZ` and `fr_DZ` locales
* Add currency providers for `ar_DZ` and `fr_DZ` locales
* Add `date_time` provider for `ar_DZ` locale
* Add ssn providers for `ar_DZ` and `fr_DZ` locales
py-greenlet: updated to 3.4.0
3.4.0 (2026-04-08)
- Publish binary wheels for RiscV 64.
- Fix multiple rare crash paths during interpreter shutdown.
Note that this now relies on the ``atexit`` module, and introduces
subtle API changes during interpreter shutdown (for example,
``getcurrent`` is no longer available once the ``atexit`` callback fires).
- Address the results of an automated code audit performed by
Daniel Diniz. This includes several minor correctness changes that
theoretically could have been crashing bugs, but typically only in
very rare circumstances.
- Fix several race conditions that could arise in free-threaded
builds when using greenlet objects from multiple threads, some of
which could lead to assertion failures or interpreter crashes.
opensc: updated to 0.27.1
New in 0.27.1; 2026-03-31
* Bugfix release to fix up infrastructure issues.
New in 0.27.0; 2026-03-30
Security
* CVE-2025-13763: Several uses of potentially uninitialized memory detected by fuzzers
* CVE-2025-49010: Possible write beyond buffer bounds during processing of GET RESPONSE APDU
* CVE-2025-66215: Possible write beyond buffer bounds in oberthur driver
* CVE-2025-66038: Possible read beyond buffer bounds when parsing historical bytes in PIV driver
* CVE-2025-66037: Possible buffer overrun while parsing SPKI
* More low-severity data handling issues when parsing profile configuration
General improvements
* Added support for PKCS#11 3.2 in tools and pkcs11-spy and p11test
* Added support for Ed448, X448 mechanisms and improve support for
[52 lines not shown]
