[CIR] Derive lowering attr names from cppClassName, not the def name
CIRLoweringEmitter built its CXX_ABI_ALWAYS_LEGAL_ATTRS entries with
GetOpCppClassName, which splits the TableGen def name at the first
underscore. That works only while every def is named CIR_<CppClassName>Attr.
When one is not, the emitter writes an `isa<>` for a class that does not
exist, and the failure lands as a compile error in generated code.
Attributes carry the authoritative name in cppClassName, which
GenerateAttrToValueVisitor was already reading. Factor that out as
GetAttrCppClassRef and use it for both attribute paths. GetOpCppClassName
stays for operations.
NFC, and checkable. No CIR attribute overrides cppClassName, so the generated
CIRLowering.inc is byte-identical.
[CIR] Drop the redundant suffix from the inline kind mnemonic
inline_kind was the one CIR enum attribute mnemonic still repeating what its
C++ enum class name says. The attribute now spells
`#cir.inline<always_inline>`. The operation argument keeps the name
inline_kind, since that is the accessor name, so the printed form reads
`inline_kind = #cir.inline<always_inline>`.
The enum's summary also becomes "inline kind" rather than the camelCase
"inlineKind", which is what generated docs show now that CIR_InlineKindAttr
no longer overrides it.
25 CHECK lines change across four test files. Nine are in an
aarch64-registered-target test, unsupported in an X86-only build, but the
substitution matches the two CIR tests that do run.
[CIR] Use the modern enum case classes
The `I32EnumAttrCase` family carries an `Attr` half, and an `IntegerAttr`
predicate with it, that a CIR enum has no use for now that the enums derive
from `EnumInfo`. Upstream says of those forms that they "are not needed when
using the newer `EnumCase` form".
Rename all 198 of them to `I32EnumCase`, `I32BitEnumCaseNone`,
`I32BitEnumCaseBit` and `BitEnumCaseGroup`. The group class drops its width
prefix because the modern spelling takes the width from its cases.
NFC, mechanical.
tests/sys/kern/ssl_sendfile: fix the build with ATF 0.22+
Code that assigned variables as part of ATF_\* are no longer
permitted due to changes introduced in [ATF 0.22][1].
MFC after: 2 weeks
Reported by: clang/gcc (-Wparenthesis)
Differential Revision: https://reviews.freebsd.org/D59286
[1]: https://github.com/freebsd/atf/pull/72
[CIR] Drop dead ceremony around the CIR enum attributes
Five things that no longer earn their place in the CIR enum attribute
machinery.
CIR_CleanupKindAttr carried three. Its cppClassName restated the default
AttrDef already derives. Its skipDefaultBuilders plus hand-written
AttrBuilder existed only to default $value to CleanupKind::All, which no
caller relies on, so the generated builders stayed suppressed for nothing.
And its summary and description restated the name, overriding the enum's own
"cleanup kind" that EnumAttr would otherwise inherit. The isNormal, isEH and
isNormalAndEH helpers stay.
CIR_TLSModelAttr's summary restated its name the same way, so only that goes.
CIR_DefaultValuedEnumParameter has never had a user.
NFC.
[CIR] Migrate the FPClassTest bit enum and unquote its flags
cir.is_fp_class printed its flags inconsistently. Single-bit values came out
bare, as in `fcSNan`, while group values and combinations came out quoted, as
in `"fcInf"` and `"fcSNan|fcNegInf"`. That comes from I32BitEnumAttr setting
printBitEnumQuoted, which EnumAttr.td keeps only for backwards compatibility.
Clearing the bit and using the `enum` directive selects the separator-aware
parser and printer, so every value now spells unquoted:
cir.is_fp_class %x, fcSNan|fcNegInf : (!cir.float) -> !cir.bool
The enum also drops its specialized IntegerAttr for a CIR_EnumAttr wrapper,
giving it the standalone spelling `#cir.fp_class<fcSNan|fcNegInf>`. This
changes operation syntax, so it updates 37 CHECK lines.
[CIR] Move the CIR enums off the legacy EnumAttrInfo hierarchy
MLIR has two enum hierarchies. `EnumAttrInfo` doubles as an `IntegerAttr`
constraint, so every CIR enum had to clear `genSpecializedAttr` to say it did
not want one. `EnumInfo` describes a C++ enum and nothing more.
Derive the CIR bases from `I32Enum`, `I64Enum` and `I32BitEnum`, and widen
`CIR_EnumAttr` to the `EnumInfo` that upstream `EnumAttr` already takes. The
flag no longer exists to clear. `FPClassTestEnum` gets unquoted printing from
`BitEnumBase` rather than overriding `printBitEnumQuoted`, and
`CIR_KnownFuncKind` drops a `parameterPrinter` the generated `operator<<`
now covers, still spelling `#cir.func_identity<"std::find">`.
AMDGPU wraps an `I32Enum` in an `EnumAttr` with this same bracketed format.
Parsing moves to the generated `FieldParser`, whose diagnostic names the
accepted spellings, so two `expected-error` lines change. Generated attribute
code drops 16 KB as 28 inlined parsers collapse into it.
security/headscale: Update 0.27.1 => 0.29.3
While here:
- Remove the space between BROKEN_* and NOT_FOR_ARCHS*
to clear a few of portlint warnings.
- Add updating notes to pkg-message for breaking changes.
Changelog:
https://github.com/juanfont/headscale/blob/v0.29.3/CHANGELOG.md
PR: 297493
Approved by: Michael Muenz <m.muenz at gmail.com> (maintainer timeout, 3+ weeks)
Approved by: osa, vvd (Mentors, implicit)
[flang-rt] Initialize I/O unit storage read by short-circuit predicates (#221126)
ConnectionState and OpenFile hold common::optional members read through
predicates of the form `opt && x < *opt`, which never use an indeterminate
value in the abstract machine. Compilers do, however, routinely if-convert
the short-circuit && into a branchless compare and select, which speculates
the payload load; because these objects are placement-new'd into malloc'd
storage by UnitMap::Create(), a memory checker then reports a conditional
branch that depends on uninitialized memory. On AArch64 this fires for
every Fortran program that writes a record, giving two reports in
ExternalFileUnit::AdvanceRecord() from IsAfterEndfile() and IsAtEOF(),
while x86-64 is unaffected and libgfortran is clean on the same program and
host. The reports are false positives -- the engaged flag is 0, so both arms
of the select are 0 -- but they are unavoidable noise for anyone running
Valgrind on Fortran code.
Add common::ResetWithDefinedPayload(), which leaves an optional disengaged
while writing its payload storage, and call it at construction for the
optionals in ConnectionAttributes, ConnectionState and OpenFile. Also
[15 lines not shown]
japanese/skkinput3: Mark DEPRECATED
Abandoned, cannot be executed on amd64 due to an error.
$ skkinput3
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 18 (X_ChangeProperty)
Value in failed request: 0x40
Serial number of failed request: 39
Current serial number in output stream: 40
PR: 297763
Approved by: koma2 at lovepeers.org (maintainer timeout, 2 weeks)
Approved by: osa (mentor)
MFH: 2026Q3
(cherry picked from commit bff649cccba209035ad4d37dc12b29e368c7a284)
[flang] Reclassify MVBITS, SPLIT, and TOKENIZE as SIMPLE (#205024)
F2023 makes MVBITS a simple elemental subroutine and SPLIT/TOKENIZE
simple subroutines.
This change:
- adds `simpleSubroutine` and `simpleElementalSubroutine` to
`IntrinsicClass`,
- reclassifies the MVBITS, SPLIT, and TOKENIZE intrinsic table entries,
- propagates `SIMPLE` through intrinsic resolution and procedure
characteristics.
MOVE_ALLOC is not included in this change.
japanese/skkinput3: Mark DEPRECATED
Abandoned, cannot be executed on amd64 due to an error.
$ skkinput3
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 18 (X_ChangeProperty)
Value in failed request: 0x40
Serial number of failed request: 39
Current serial number in output stream: 40
PR: 297763
Approved by: koma2 at lovepeers.org (maintainer timeout, 2 weeks)
Approved by: osa (mentor)
MFH: 2026Q3
Use getexecpath(3). Since this is crucial build tooling, if getexecpath(3)
fails, fallback to the old method in case someone tries to build on an old
system. Future clang updates should not contain this fallback code chunk.
ok kettenis
Replace argv[0] with execvp(3) for fork+exec privsep with getexecpath(3)
and execv(3).
(this lpd is an incomplete replacement which has never been finished, but
maybe eventually someone will finish it...)
