uipc_usrreq: revert addition of EMPTYPATH for bindat(2)
The caller wants the parent vnode, which cannot be provided for emptypath
lookups.
Reported and reviewed by: markj
Fixes: 12c590a9abd7 ("bindat(2)/connectat(2): allow implicit EMPTYPATH for unix domain sockets")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57448
Interfaces: Assignments - refactor to MVC for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
[clang][lex] Store `HeaderFileInfo` in a `DenseMap` (#200968)
Calling `FileManager::GetUniqueIDMapping()` during modular builds gets
very expensive if the `FileManager` has seen lots of files. This
function is used in two places in the `ASTWriter` to look up
`HeaderFileInfo` in `HeaderSearch`.
This PR changes the storage of `HeaderFileInfo` from
`FileEntry::getUID()`-indexed `std::vector<T>` to
`llvm::DenseMap<FileEntryRef, T>`, improving scanning performance by
~2.5%.
[flang][acc] Attach FortranObjectViewOpInterface to acc.unwrap_private (#201646)
Since this operation is simply a zero-offset view, attach the
FortranObjectViewOpInterface to allow FIR AA to walk this if needed.
Interfaces: Assignments - work in progress for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
[lldb][docs] Convert use/ RST docs to Markdown (NFC) (#201467)
Convert the ten user-facing RST docs under lldb/docs/use/ to MyST
Markdown. This is the third batch of an incremental RST -> Markdown
migration; PR1 covered the small leaf pages and PR2 covered the
contributor-facing docs under resources/.
Files: formatting, intel_pt, map, remote, symbolfilejson, symbolication,
symbols, troubleshooting, tutorial, variable.
Verified by building the docs on origin/main and on this branch with
identical sphinx flags and diffing both the warnings and the rendered
HTML. After file extension and line numbers are normalized, the warning
sets match exactly. Seven of the ten pages are byte-identical. The three
that differ (symbolication, tutorial, variable) differ only in
CommonMark collapsing two-spaces-after-period to one and MyST renaming
auto-numbered footnote IDs (`id6` -> `footnote-1`) plus adding an `<hr>`
separator before footnote sections.
[17 lines not shown]
[AArch64] Fold UMOV(lane 0) + GPR store in FPR store (#199139)
Problem: LLVM generates `umov w8, v0.h[0]` + `strh w8, [x0]` instead of
`str h0, [x0]` when storing vector lane 0 to memory, specifically when
SimplifyCFG merges stores across branches -- splitting the
extractelement and store into different basic blocks and preventing the
existing DAG combine from firing.
https://godbolt.org/z/v5G9ohMPa
Root cause: SimplifyCFG creates a PHI + merged store in a successor
block. SelectionDAG ISel processes each block independently, so it
lowers the extract to `UMOV` (GPR) in the predecessor and the store sees
only a GPR value via the PHI. Late tail duplication puts the store back
in the same block, but the `UMOV` is already baked in.
Fix: Added a post-RA peephole in `AArch64LoadStoreOptimizer` (step 6 in
`optimizeBlock`) that recognizes `UMOVvi*_idx0` + GPR store patterns and
replaces them with direct FPR sub-register stores. The peephole:
[13 lines not shown]
[ThinLTO][AIX] Teach ModuleSummaryAnalysis to include globals
referenced via !implicit.ref metadata as explicit reference edges in the ThinLTO
module summary via a new helper findImplicitRefEdges. Add imported
implicit ref strings (available_externally GVs) to llvm.compiler.used during thinLTO interaction with pragma comment copyright.
[flang][docs] Documented `c_float128` and `c_float128_complex` extension (#201614)
flang has supported this for a long time, but it wasn't documented as an
extension
[CIR] Lower constant block addresses for goto
GNU computed-goto code that takes a label's address in a constant
context -- the common static dispatch-table idiom
`static const void *tbl[] = {&&L1, &&L2}; goto *tbl[i];` -- hit
`errorNYI` in `ConstantLValueEmitter::VisitAddrLabelExpr`, and the
follow-on `goto *tbl[i]` then tripped the `indirectGotoBlock`
assertion in `emitIndirectGotoStmt` because the label was never
registered as address-taken. The runtime form (`void *p = &&L;
goto *p;`) already worked; only the constant form was missing.
Label addresses had no constant representation: `cir.block_address`
existed only as an operation, which cannot appear inside a
`#cir.const_array` initializer. Add a `#cir.block_address` constant
attribute and lower it to MLIR's `LLVM::BlockAddressAttr`, reusing the
same `BlockTagOp` resolution the operation form already uses
(threading the pass-owned `LLVMBlockAddressInfo` into the constant
value lowering and the Global/Constant lowering patterns).
[12 lines not shown]