et-mgmt/zabbix74-server: fix mariadb dependencies
Since database/mariadb105-server and databases/mariadb106-server
are now removed from ports, zabbix74-server cannot be built with
mariadb as database.
This fix this issue and add all mariadb versions supported by
Mk/Uses/mysql.mk
PR: 297242
Approved by: maintainer timeout (otis)
Sponsored by: NBER
Sponsored by: Klara, Inc.
et-mgmt/zabbix74-server: fix mariadb dependencies
Since database/mariadb105-server and databases/mariadb106-server
are now removed from ports, zabbix74-server cannot be built with
mariadb as database.
This fix this issue and add all mariadb versions supported by
Mk/Uses/mysql.mk
PR: 297242
Approved by: maintainer timeout (otis)
Sponsored by: NBER
Sponsored by: Klara, Inc.
rpki-client: unconditionally warn about incorrect RSA parameters
Now that ARIN have fixed their old ROAs, this encoding no longer occurs
in the wild, so enabling this warning does no harm. Ideally we'd error,
but a Postel-inspired MUST that has been sprinkled across numerous RFCs
ensured that this had to be tolerated for more than a quarter of a century
and will continue to be for at least another one.
discussed with claudio job
[flang][PFT] Mark ASSIGN'd labels as assigned GO TO targets
An assigned GO TO with an explicit label list only marked the listed
labels as branch targets. Lowering is more permissive: genFIR for
AssignedGotoStmt in flang/lib/Lower/Bridge.cpp builds the switch from the
labels ASSIGN'd to the variable and ignores the list.
A construct holding an ASSIGN'd label that the list omits therefore
looked wrappable, was placed in an scf.execute_region, and the branch
then crossed a region boundary:
error: 'fir.select' op branching to block of a different region
Mark both sets so the wrappability analysis sees every escape.
[mlir][VectorToLLVM] Use the converted index type in vector.type_cast
`VectorTypeCastOpConversion` hardcoded `i64` for the offset, size and stride
constants it inserts into the target memref descriptor, while the descriptor's
fields have the converted index type. With a type converter configured for a
32-bit index the pattern therefore emitted invalid IR:
'llvm.insertvalue' op Type mismatch: cannot insert 'i64' into
'!llvm.struct<(ptr, ptr, i32)>'
Build the constants from the converted index type instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[mlir][NFC] Share createIndexAttrConstant as a free function (#218736)
The `LLVM::ConstantOp` with an index-typed attribute idiom existed in
three byte-identical copies: the protected `ConvertToLLVMPattern`
member, a file-static helper in `MemRefBuilder.cpp`, and open-coded in
the free function `mlir::LLVM::getStridedElementPtr`, which cannot reach
the protected member.
Promote a single free `mlir::LLVM::createIndexAttrConstant` and route
all three through it, so that a change to how these constants are built
has one place to happen.
Co-authored-by: Claude Opus 5 (1M context) <noreply at anthropic.com>
[clang][CodeGen] Skip __hip_cuid_ global in incremental(clang-repl) mode (#217228)
With this patch, when run in incremental mode (clang-repl), Clang skips
emitting the `__hip_cuid_` global. This is handled in
`clang/lib/CodeGen/CodeGenModule.cpp` on
`LangOpts.IncrementalExtensions`.
I have also added a test at
`clang/test/CodeGenCUDA/hip-cuid-incremental.hip` which checks that the
`__hip_cuid_` global is emitted normally but not in the presence of
`-fincremental-extensions`.
Assisted by Claude Opus 4.8
[mlir][MPIToLLVM] Take the descriptor index type from the descriptor
`getRawPtrAndSize` extracted the memref descriptor's offset as `i64` and
unconditionally truncated the extents to `i32`. Both assume a 64-bit index: with
a 32-bit one the extract disagrees with the descriptor's field type and the
truncation becomes an invalid `llvm.trunc` from `i32` to `i32`.
Read the index type off the descriptor and only adjust the extent width when it
actually differs. While here, drop the rank-0 branch that rebuilt the already
available element count as an `arith.constant` in the middle of an LLVM
lowering.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
