www/py-wagtail-2fa: Move away from py-dj52-* ports
* The counterparts of the py-dj52-* ports were switched to Django 5.2 in
ce59801b72ef, thus move py-wagtail-2fa to those ones.
* Bump PORTREVISION due changed dependencies.
PR: 291707
Approved by: sunpoet (maintainer, via private mail)
www/py-wagtail-airtable: Move away from py-dj52-* ports
* The counterparts of the py-dj52-* ports were switched to Django 5.2 in
ce59801b72ef, thus move py-wagtail-airtable to those ones.
* Bump PORTREVISION due dependency change.
PR: 291707
Approved by: sunpoet (maintainer, via private mail)
www/py-wagtail: Move away from py-dj52-* ports
* The counterparts of the py-dj52-* ports were switched to Django 5.2
in ce59801b72ef, thus move py-wagtail to those ones. Do the same
for www/py-modelsearch as well.
* Bump PORTREVISION due dependency change.
PR: 291707
Approved by: sunpoet (maintainer, via private mail)
[libc++] Fix multi{map,set}::extract not returning the first matching element (#199703)
According to [associative.reqmts] `extract(k)` returns the _first_
element in the container with key equivalent to k.
(cherry picked from commit 72871f6fa1f1edc3df45d01b67f5093ff9d8e8b5)
[LLD] [COFF] Fix handling of immediates in ARM64_SECREL_HIGH12A (#200060)
Just like for PAGEBASE_REL21, the immediate in SECREL_HIGH12A is the
byte offset, not a page offset. The byte level offset is added to the
symbol offset, which only then after that gets shifted right by 12. This
makes the handling of this immediate consistent with what MS link.exe
does.
The existing testcase had a zero immediate in the instruction for this
relocation.
This makes it clear that immediate offsets with SECREL_HIGH12A do work
fine, where the byte level offsets end up carrying over to the upper
bits.
(cherry picked from commit 5c95f6a859394757b92b0d63ff90b9175056deb6)
[PowerPC] Drop invalid range metadata when lowering i64 load to fp in INT_TO_FP (#198705)
When lowering an i64 load in LowerINT_TO_FP, we were forwarding the
original !range metadata to a new f64 load. This is invalid because the
metadata no longer matches the value type/semantics, and can trigger
assertions when lowering i64 to fp (double or float) conversions.
This patch fixes this by passing a nullptr for the Ranges operand when
calling getLoad() and adds extra test cases to cover signed/unsigned i64
to f32/f64 conversions and to ensure they do not assert when the !range
metadata is present.
The assertion this patch attempts to fix is:
```
Assertion failed: (!MMO->getRanges() || (mdconst::extract<ConstantInt>(MMO->getRanges()->getOperand(0)) ->getBitWidth() == MemVT.getScalarSizeInBits() && MemVT.isInteger())) && "Range metadata and load type must match!"
```
This assert was originally seen when building Rust on AIX.
(cherry picked from commit 78f5f7717a2e058c4d685feb3edb7d991efacbc2)
[X86] lowerV64I8Shuffle - avoid lowerShuffleAsRepeatedMaskAndLanePermute call on VBMI targets (#183109)
Shuffle combining fails to fold the inner shuffles first, but luckily the LanePermuteAnd* methods are enough if we have VPERMB as a fallback
Fixes #137422
(cherry picked from commit 1b9fea021840f17c41ea980300d0fc45e7285909)
[X86] lowerV64I8Shuffle - prefer VPERMV3 byte shuffles to OR(PSHUFB,PSHUFB) on VBMI targets (#182852)
Minor improvement for #137422
(cherry picked from commit 8f5880d3ae4e5dfc748985d90e5413671028aa3e)
[AArch64] Generate umaddl and smaddl from disjoint or (#200198)
Similar to other patches recently, this adds add_like handling to the
tablegen patterns for smaddl and umaddl, allowing them to match from
disjoint or.
[PowerPC] Fix i128 vcmpequb optimization for loads with range metadata and small constants (#196801)
The combine introduced in 55aff64d2c6ef50d2ed725d7dd1fb34080486237
lowers scalar i128 compares into vector compares by reissuing the
original loads as v16i8 loads. However, the combine was reusing the
original MachineMemOperand without modification.
If the original i128 load carries !range metadata, the MMO encodes that
range using i128 values. Reusing this MMO for a v16i8 load is incorrect
as range metadata is only valid for integer scalar types and its
bitwidth must match the memory VT.
This patch fixes this by creating a new MachineMemOperand for the vector
vector load. Additionally, we restrict the combine for constant operands
to avoid cases that are better handled by scalar lowering. Small
constants (fit within 16 bits) are excluded to prevent generating
suboptimal vector compares.
(cherry picked from commit 1907b586384b51be2f6b44490c46941f08ff6974)
[AMDGPU] A Vulkan-style memory model weaker than the LLVM model (#191246)
Add a new AMDGPU memory model specification that is weaker than the LLVM
memory model using Vulkan-style availability/visibility semantics and
scoped operations. The model allows more efficient implementations while
maintaining a safe-by-default mapping to the standard LLVM model.
**RFC:**
https://discourse.llvm.org/t/a-vulkan-style-memory-model-for-amdgpu-and-beyond/90498
Related changes:
- #191390
- #199489
[libc] Add sys/param.h header (#200559)
Added the sys/param.h header containing standard BSD macros:
* NBBY
* MIN and MAX
* howmany, roundup, and powerof2
* MAXPATHLEN
The macros are defined in llvm-libc-macros/sys-param-macros.h with
guards to prevent redefinition conflicts.
Enabled the header for x86_64, aarch64, riscv, and arm Linux targets.
Assisted-by: Automated tooling, human reviewed.
