java/openjdk11: Update to 11.0.33, incl eMudhra fixes
Update to latest upstream patch version to address issues with the
eMudhra certificate incident.
See also: https://openjdk.org/emudhra
MFH: 2026Q4
Security: CVE 2026-114820
Security: JDK-8395690
Sponsored by: The FreeBSD Foundation
[SLP][modularisation][NFC] Move BoUpSLP-independent helpers to SLP util modules (#237651)
Move file-local helpers that do not depend on BoUpSLP out of
SLPVectorizer.cpp into the self-contained SLPVectorizer/ modules:
- SLPCostAnalysis: buildIntrinsicArgTypes, getVectorCallCosts,
isPoorThroughputOp (with PoorThroughputOpCache, getVectorOpCost and
getPoorThroughputTypeKey), isFusableFMulOperand,
getVectorInstrContextHint, hasHighRegisterPressure.
- SLPCompatibilityAnalysis: getMainAltOpsNoStateVL, checkEVsForVecCalls.
- SLPShuffleAnalysis: performExtractsShuffleAction (with ValueSelect).
- SLPUtils: areTwoInsertFromSameBuildVector.
- SLPReductionUtils: the body of HorizontalReduction::getRdxKind, which
now forwards to it. This drops the file-static getRdxKind wrapper that
called back into HorizontalReduction.
Part of the SLPVectorizer.cpp modularization effort:
https://discourse.llvm.org/t/modularizing-slpvectorizer-cpp/90922
Assisted by AI
multimedia/moviebox-tui: fix dependency
Spotted by leot@ during mpv revbump.
moviebox-tui only depends on the mpv executable.
While here remove duplicate line.
[NFC][SelectionDAG] Removed canOpTrap, migrating callers to isSafeToSpeculativelyExecute. (#238906)
The implementation of canOpTrap seems to answer a different question
because there are many trapping operations not accounted for. The
the only use really wants to know if it's safe to widen a lane-wise
operation by concatenating poison lanes to its operands.
[X86] Add thorough vector.interleave/deinterleave test coverage (#239549)
Based off the existing vector-interleaved-store/load tests
Small step towards fully supporting vector.interleave/deinterleave
intrinsics - this is mainly to show what we're up against :(
First half of #234626
[flang][cuda] Release allocatable function results with their allocator (#239042)
Under `-gpu=unified`, a plain allocatable function result gets the
unified allocator, so the callee allocates it with that allocator. The
caller still moved the result into an `hlfir.expr`, whose buffer is
released with an inlined `free`, so a program like `s = trim(f())` with
a `character(:), allocatable` result crashed in `free()`.
A result with a CUDA data attribute was already kept as a variable and
released with the CUDA-aware deallocation (209945). This extends that
path to every allocatable result under `-gpu=unified`. The cleanup of a
result that must be destroyed (a derived type with allocatable
components or a final procedure) had the same problem for both kinds of
result, because it always freed the result inline. It now releases the
storage through `AllocatableDeallocateNoFinal`, which uses the allocator
recorded in the descriptor and does not finalize the result a second
time.
Because such a result is kept as a variable, it is no longer moved into
[5 lines not shown]
[Clang] Fix false-positive fallthrough warning (#234848)
substatement of a case label can be wrapped in an AttributedStmt when
attributes like [[likely]] or [[unlikely]] are used. Because of this,
directly comparing the substatement pointer with the next block's label
can fail even when they refer to the same underlying case label. I put
helper function stripAttributedStmts() to unwrap nested AttributedStmt
and return underlying statement and used it in the comparisons for
SwitchCase and LabelStmt in checkFallThroughIntoBlock() to get correct
comparision check even with attrbuted labels.
- Added regression tests in
`clang/test/SemaCXX/switch-implicit-fallthrough.cpp` for the reported
issue.
#LLM usage
I used LLM to help understand the existing Clang code, investigate the
[4 lines not shown]
[AMDGPU][CodeGen] Move rematerialization strategy out of scheduler (NFC) (#238850)
This un-ties the rematerialization strategy based on the
target-independent `Rematerializer` from the `PreRARematStage`, allowing
its use at different points in the pipeline and making future changes to
the strategy easier thanks to better separation of concerns. The
strategy is moved as-is with no functional changes at the moment.
stop trying to refuse a whole bunch of ioctls when securelevel > 1, which
was advertised as "pf filter and NAT rules may not be altered" - however,
there are numerous other ways, like turning pf of per-interface using set
skip, removing/adding interfaces from/to groups etc etc etc
root is root, period. pf doesn't have anything securelevel-dependent now.
"set skip" reported by acts1631kjv at proton
support deraadt, ok sashan claudio sthen
msun: fix behaviour of nextafter*() and nexttoward*() for MAX value
For an edge case at an extreme, e.g., nextafter(-DBL_MAX,-INFINITY)
do not return x+x. Instead, evaluate x+x and assign it to a volatile
to raise an exception, and then fall through to return the correct
result in current rounding mode.
PR: 299389
MFC after: 6 days (for inclusion into releng/15.2)
(cherry picked from commit 1fb5d8265bc4bbbf1f5bc79cc1d2a7f280b446b2)
msun: fix behaviour of nextafter*() and nexttoward*() for MAX value
For an edge case at an extreme, e.g., nextafter(-DBL_MAX,-INFINITY)
do not return x+x. Instead, evaluate x+x and assign it to a volatile
to raise an exception, and then fall through to return the correct
result in current rounding mode.
PR: 299389
MFC after: 6 days (for inclusion into releng/15.2)
(cherry picked from commit 1fb5d8265bc4bbbf1f5bc79cc1d2a7f280b446b2)
