golang/go · error
Loong64 extension: invalid LSX/LASX arrangement type: {ext}
Error message
Loong64 extension: invalid LSX/LASX arrangement type: {ext} What it means
Thrown by Loong64RegisterExtension when an LSX/LASX register is used in an index (element-access) context but the extension string `ext` is not a key in loong64ElemExtMap. The index-branch only accepts the eight element-type suffixes B, H, W, V, BU, HU, WU, VU; anything else (including a valid arrangement suffix like B16) is rejected here because index access encodes an element width, not a full vector arrangement.
Source
Thrown at src/cmd/asm/internal/arch/loong64.go:96
var arngType int16
var simdType int16
var simdReg int16
switch {
case reg >= loong64.REG_V0 && reg <= loong64.REG_V31:
simdType = loong64.LSX
simdReg = reg - loong64.REG_V0
case reg >= loong64.REG_X0 && reg <= loong64.REG_X31:
simdType = loong64.LASX
simdReg = reg - loong64.REG_X0
default:
return errors.New("Loong64 extension: invalid LSX/LASX register: " + fmt.Sprintf("%d", reg))
}
if isIndex {
arngType, ok = loong64ElemExtMap[ext]
if !ok {
return errors.New("Loong64 extension: invalid LSX/LASX arrangement type: " + ext)
}
a.Reg = loong64.REG_ELEM
a.Reg += ((simdReg & loong64.EXT_REG_MASK) << loong64.EXT_REG_SHIFT)
a.Reg += ((arngType & loong64.EXT_TYPE_MASK) << loong64.EXT_TYPE_SHIFT)
a.Reg += ((simdType & loong64.EXT_SIMDTYPE_MASK) << loong64.EXT_SIMDTYPE_SHIFT)
a.Index = num
} else {
switch simdType {
case loong64.LSX:
arngType, ok = loong64LsxArngExtMap[ext]
if !ok {
return errors.New("Loong64 extension: invalid LSX arrangement type: " + ext)
}
case loong64.LASX:
arngType, ok = loong64LasxArngExtMap[ext]
if !ok {View on GitHub (pinned to b6b368adc5)
Solutions
- Change the index suffix to one of the valid element types: B, H, W, V, BU, HU, WU, or VU.
- If you intended a full-vector arrangement rather than an element access, remove the index form (drop the `[N]` / isIndex usage) so the arrangement-branch (errors 61/62) applies instead.
- Double-check whether the register is V0-V31 (LSX) or X0-X31 (LASX); element suffixes are shared but arrangement suffixes differ per SIMD width.
Example fix
// before (invalid index suffix) VADDI V0.B16[0], V1, V2 // after (valid element suffix for indexed access) VADDI V0.B[0], V1, V2
Defensive patterns
Strategy: validation
Validate before calling
// Validate an LSX/LASX index element suffix before assembling.
var validElemExt = map[string]bool{"B":true,"H":true,"W":true,"V":true,"BU":true,"HU":true,"WU":true,"VU":true}
func validIndexExt(ext string) bool { return validElemExt[ext] } Type guard
// n/a: Loong64 assembly suffixes are strings, validated by lookup.
func isValidLoong64ElemExt(ext string) bool {
switch ext { case "B","H","W","V","BU","HU","WU","VU": return true }
return false
} Prevention
- Keep a reference table of element vs arrangement suffixes for LSX (128-bit) and LASX (256-bit).
- Run `go vet`/assembly test builds in CI for Loong64 targets to catch suffix typos early.
- Differentiate indexed access (element width) from full-vector arrangement when writing operands.
When it happens
Trigger: Calling Loong64RegisterExtension with isIndex==true and an `ext` value absent from loong64ElemExtMap. In hand-written or generated Loong64 assembly this maps to an indexed vector operand like `V0[B]` where the bracketed suffix is not one of B/H/W/V/BU/HU/WU/VU.
Common situations: Authoring Loong64 SIMD assembly (LSX/LASX) and using an arrangement suffix (e.g. B16, H8) instead of an element suffix on an indexed access; typos in the element-width specifier; porting ARM SVE/NEON or RISC-V V assembly syntax that uses different suffix names.
Related errors
- Loong64 extension: invalid LSX arrangement type: {ext}
- Loong64 extension: invalid LASX arrangement type: {ext}
- Loong64 extension: invalid LSX/LASX register: {reg}
- invalid register for shift operation
- expect V0-V31, Z0-Z31, or P0-P15; found: {name}
AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12).
Data as JSON: /api/errors/d1482393f3ea04f6.
Report an issue: GitHub.