[Instrumentor] Use CreateAllocationSize to compute size of alloca (#226330)
No significant functional change, but the IR might look slightly
different.
[Clang] Enforce the same size limits for `vector_size` and `ext_vector_type` (#226375)
Fixes #165458
A `bool` vector declared with `ext_vector_type` isn't lowered as an LLVM
vector in memory: `ConvertTypeForMem` packs it into a single integer
with one bit per element. `BuildExtVectorType` only checked that the
element count fits in 32 bits, though, so a vector of 187,553,262 bools
got through Sema and the first consumer that needed its memory type (the
zero initializer of a tentative definition here) asked
`IntegerType::get` for far more than the 2^23 bits it supports. The
count matters for every element type, not just `bool`, because Sema also
forms bool vectors out of other vectors (`c ? true : false` with a
`char` vector condition), and `vector_size` was no better off with its
limits of 2^32 elements and 2^61 bytes.
Both attributes now go through the same two limits when the type is
built, reusing the existing "vector size too large" error: at most
`llvm::IntegerType::MAX_INT_BITS` (2^23) elements, and at most 2^28
[2 lines not shown]
[llvm] produce a more consistent estimates of bit width needed when parsing an integer (#205947)
A colleague of mine noticed that `"12535824225335233"` parses in MLIR's
integer attribute parser as a 68-bit integer, even though it is a 53-bit
constant. I traced this back to `StringRef::consumeInteger`'s heuristic
estimate of the bit size. This change replaces that heuristic with a
default 64-bit storage, doubling the storage as more digits are parsed.
This produces a potentially larger over-estimate of the total storage
required, but does so in a less arbitrary manner and reduces the
over-approximation for numbers close to the 64-bit boundary.
Nb., A first iteration of this change tightened that estimate to at most
a 1-bit overapproximation with a lookup-table.
Assisted by Gemini
[clang-format] Preserve enum initializer continuation indentation (#223435)
Fixes #223011
Enum assignment operators are annotated as TT_EnumEqual so they can be
aligned independently in #194154. However, this means
ContinuationIndenter no longer recognizes a wrapped enum `=` as
TT_BinaryOperator. As a result, it may force unnecessary breaks within
the RHS binary expression.
Co-authored-by: Aaron Saw Min Sern <aaron at aaronsms.com>
[Flang][OpenMP] Fix broken offload test caused by MapInfoFinalization code movement (#226384)
This change addresses the breakage in
target-map-nested-dtype-allocatable-member.f90 I inadvertently broke it
by removing the excess bit of implicit mapping code in the
MapInfoFinalizaiton pass without correctly addressing it.
This PR tries to do so by allowing mappers to be generated for member
maps such as var1%b, var2%b, which were previously being blocked.
Currently (and conveniently for this patch) we do avoid duplicate maps
in the scenario where we specify something along the lines of:
map(tofrom: var1, var1%b, var2, var2%b)
But that is through the fact that we completely negate var1/var2's
mapper attachment in this scenario, which I do not believe is the
correct behavior. But it's the existing behavior and facilitates this
patch, but it is something I'll see if I can address in a follow up PR
[2 lines not shown]
Adjust graceful restart timer handling for multi-AFI/SAFI sessions
The timer is global for all AFI/SAFI but the first EoR would clear the timer
which then can result in stale routes. Instead stop clearing the timer and
use a new flag CAPA_GR_FINISHED. The code no longer clears CAPA_GR_RESTARTING
on EoR but instead sets CAPA_GR_FINISHED and so when the timer fires the
loop over all AFI/SAFI pairs will will skip all the ones that only have
CAPA_GR_RESTARTING set (but no CAPA_GR_FINISHED).
On top of this improve parse_capabilities() by respecting that only the last
instance of the capability matters. Also make sure capa_neg_calc() does not
write anything to capa.neg.grestart if the capability is disabled on our
end.
Reported by N0zoM1z0
OK tb@
[LoopFusion] Cleanup control flow before Fusion (#226289)
Non-loop successor of loop guard is sometimes modified by JumpThreading
(and potentially some other passes) to jump to a new block, that doesn't
post dominate the exit block of the loop:
Guard: br %c, %Preheader, %Skip
Skip: br %Merge
...
Exit: br %Merge
Merge: ...
Later on, this block becomes empty, so it can be removed. Its presence
prevents Loop::getLoopGuardBranch() from detecting the loop guard which
results in missed fusion opportunities. SimplifyCFG will run when "Skip"
is still not optimzied, so it cannot resolve this issue.
Assisted by Claude Code
[CIR] Keep fast-math flags on the CIR builder and address review
Drop the process-wide OpBuilder registry. CIRBaseBuilderTy now holds the
fast-math flags next to the constrained-FP state, the same way IRBuilder
does in classic CodeGen:
- CIRGenFunction::setFastMathFlags derives the flags from FPOptions (only
`contract` for now) and is called from the constructor and from
CIRGenFPOptionsRAII, which restores them like classic CodeGen's FMFGuard.
ConstrainedFPRAII restores them for nested CIRGenFunctions.
- createFAdd/FSub/FMul/FDiv/FRem go through one createFPBinOp helper that
attaches both fenv and fastmath_flags.
- Scope is limited to the FP binary ops. fneg, cmp/vec.cmp and the FP
builtins are left for follow-ups.
- The generated lowering passes op.getFastmathFlagsAttr() instead of
looking the attribute up by name.
Tests cover -ffp-contract=fast-honor-pragmas, nested pragmas with state
restored after each scope, strict FP combined with contract, and a vector
op.
[VPlan] Only exempt MaskedCond from cross-block dominance in verifier. (#226512)
Previously the verifier skipped all use-before-def checks for
MaskedCond, including uses in the same block before the definition.
Restrict the exemption to users in blocks not dominated by the
MaskedCond's block, so same-block use-before-def is still diagnosed.
[SLP]Reuse the trimmed nodes in the perfectly matched gathers of the same user
The gather node, perfectly matching the node of the same user
transformed to gather during throttling, did not treat this node as a
reuse source, and was costed and emitted as a separate buildvector.
Fixes #219030
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/226582
Merge tag 'cifs-fixes-7.3-rc5' of https://git.manguebit.org/linux
Pull smb client fixes from Paulo Alcantara:
- Fix leaked server handles and dropped errors in the SMB2 compound
create path: a parsing error reported as success, an earlier CREATE
left open when a later command fails, the cached directory open
losing the FID needed for cleanup, and SMB2_open() not closing the
handle after a create-context parse failure
- Fix out-of-bounds reads when parsing create contexts from a
malicious server: bound each context by its Next field, parse the
lease and QFid contexts from their declared offsets and validate
the POSIX create context length
- Fix a double credit decrement, and its warning, when a compound
send fails and triggers a reconnect; found by syzbot
- Fix a dentry and server handle leak in cifs_atomic_open() when an
[17 lines not shown]
Mk: Drop test dependencies from the unified dependency list
TEST_DEPENDS_ALL was part of _UNIFIED_DEPENDS, so test-only
dependencies leaked into all-depends-list, missing,
clean-depends, fetch-recursive, deinstall-depends and the QA
checks, even though they are not needed to build, package or
install a port. It pollutes all the convenience -recursive targets
including poudriere options.
They are still installed by "make test" through the test-depends
target, which is now documented as well.
The motivation for this patch is the fact that many ports now
end up having chromium as part of their dependency list following
the new dependency needed to upgrade py-great-table
(15ce974d8e0560b8038db69598cdf68c52273e68)
Reviewed by: mat@ (portmgr)
Reported by: wollman (portmgr)
Differential Revision: https://reviews.freebsd.org/D60032
[AArch64] Rename memory hints to avoid clash with arm_acle.h macros (#226432)
Renames the hints in AArch64MemoryHints.h, as HINT_STSHH_KEEP and
HINT_STSHH_STRM are already defined in arm_acle.h.
