[libc++][ranges] Mark LWG4242 as Resolved (#211568)
Closes https://github.com/llvm/llvm-project/issues/148224
The current implementation for the `ranges::distance(I&& first, S last)`
overload already sidesteps the `volatile first` with condition
`sized_sentinel_for<_Sp, __remove_cvref_t<_Ip>>`.
In the commit initially implementing `ranges::distance`
(c965d5448ecdf9a5513983862a78a2ba8f7fbab8), the condition was
`sized_sentinel_for<_Sp, __uncvref_t<_Ip>>` and `__uncvref_t` was just
renamed to `__remove_cvref_t` later. Also, given the overload has been
constrained with `sized_sentinel_for<_Sp, decay_t<_Ip>>`, the condition
always gives the same results as `!is_array_v<remove_reference_t<_Ip>>`
that is indicated by the resolution of LWG4242. So it can be considered
that LWG4242 was implemented in libc++ in LLVM 14.
This commit marks LWG4242 as Resolved and organises the test suite to
better represent both LWG3664 and LWG4242 tests in
[6 lines not shown]
[clang][bytecode] Handle invalid lambda static invokers better (#215091)
Instead of marking it as valid, mark it as constexpr, which means it
won't be valid unless it actually has valid code attached.
[InstCombine] Fold consecutive udivs into a single udiv (#214541)
Extend the existing `(X / C1) / C2 -> X / (C1 * C2)` fold to variable
divisors:
(X udiv Y) udiv Z -> X udiv (Y * Z) if Y * Z does not overflow
Uses willNotOverflowUnsignedMul to prove the product doesn't wrap.
Instruction count is unchanged but a division becomes a multiplication,
similar to the existing cttz-based udiv->lshr fold in visitUDiv.
One-use on the inner div, since otherwise we'd add a mul without
removing
the div. exact only propagates when both divides are exact.
Alive2: https://alive2.llvm.org/ce/z/qV6UJH
Fixes #132908
Merge tag 'trace-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix use-after-free in eventfs_remove_rec()
The freeing of the eventfs_inode children used list_for_each_entry()
where the child is freed via srcu, but there's still a chance that it
gets freed. It should be using list_for_each_entry_safe().
- Fix eventfs_inode SRCU use of list in freeing
The iterator uses an SRCU protected list walk on the eventfs inodes.
The eventfs inode uses its "list" field in a union with the RCU list
head. When the inode gets added to the SRCU list it immediately
corrupts the list pointer and can cause an issue with the iterator.
Move the RCU list head to be shared with the children list head which
allows the iterator to check the parent inode if is freed before
referencing the child. Have the iterator check the parent "is_freed"
[70 lines not shown]
www/py-flask-limiter3: Remove port
The one and only consumer www/py-calibreweb now supports v4.
PR: 297376
Reported by: Matthew Wener <matthew at wener.org> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
www/py-calibreweb: Update 0.6.26 => 0.6.27
This release contains bug and security fixes, also
updated to support www/py-flask-limiter v4 which in
turn removes the need for the port www/py-flask-limiter3.
Changes:
https://github.com/janeczku/calibre-web/releases/tag/0.6.27
PR: 297375
Reported by: Matthew Wener <matthew at wener.org> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
Security: CVE-2025-6998
Security: CVE-2025-7404
MFH: 2026Q3
ttys(5): a few editorial cleanups
- name init(8) as the primary consumer of /etc/ttys and use login(1) and
ttyflags(8) as example users of the getttyent(3) interface.
- rewrite the on/off/secure more simply
- modernize EXAMPLES
- add .Xr terminfo(5) to SEE ALSO
- minor grammatical tweaks
ok sthen@
[mlir][arith][NFC] Make AtomicRMWKind switches exhaustive (#214622)
`getIdentityValueAttr` and `getReductionOp` in `ArithOps.cpp` each
handle 15 of
the 16 `AtomicRMWKind` cases and route the rest through a `default:`
label
carrying `// TODO: Add remaining reduction operations.`
That TODO cannot be completed. The only unhandled kind is `assign`,
which is
not a reduction: it has no identity element (`assign(x, e) = e`, so no
constant
`e` satisfies `assign(x, e) = x`) and no corresponding binary `arith`
op. It is
still a perfectly valid kind elsewhere — `memref.atomic_rmw` lowers it
to an
atomic `xchg` in `MemRefToLLVM.cpp` — it simply has no meaning for these
two
reduction helpers.
[39 lines not shown]
[VPlan] Verify hoist point when hoisting previous value of a recurrence. (#215084)
tryToSinkOrHoistRecurrenceUsers processes the fixed-order recurrences of
a loop one at a time and updates the plan for each of them. Once the
plan has been updated for one recurrence, the properties
hoistPreviousBeforeFORUsers relies on may no longer hold for the
recurrences processed later
Convert dominance assertion that does not hold in all cases (added test
cases) to a bail out, to a crash on the added test.
PR: https://github.com/llvm/llvm-project/pull/215084
