Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SDOT/DDOT overcount at SVE VL384 (QEMU)

Aperta
  • Qualcosa non va?
#6,102 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c
Ambito
performance

Direzione di ricerca

Start with kernel/arm64/dot_kernel_sve.c and inspect how the two-vector and one-vector cutoffs are calculated from cntw or cntd; the issue identifies the non-power-of-two lane-count assumption. Build OpenBLAS for AArch64 and run the supplied repro.c under QEMU at VL384 for both single and double precision. Done means both calls return N rather than overcounting, with the reproducer passing.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

SDOT/DDOT overcount at SVE VL384 (QEMU)

On OpenBLAS develop 277ef7801416412ee970873701fdf14d603d2c3f and release
v0.3.34, one public cblas_sdot call with N=11 returns 37 instead
of 11, and one cblas_ddot call with N=5 returns 19 instead of 5,
with forced ARMV8SVE dispatch and SVE VL384 under QEMU.

Each input vector has 128 allocated elements. X[0..N-1] and all of
Y contain 1; X[N..127] contains 2. This makes reads beyond the
requested vector length affect the result while keeping these reads
inside the allocated arrays.

QEMU 8.2.2 and 10.2.1 agree. The same two calls pass with ARMV8 and
A64FX dispatch at VL384, and with ARMV8SVE, NEOVERSEV1 and NEOVERSEV2
at VL128, 256, 512, 1024 and 2048. The V1 and V2 tables fail at VL384
like ARMV8SVE. Original Reference BLAS v3.12.1 SDOT/DDOT returns
11 and 5 on both emulators at all six tested lengths. The pass
statements describe these two reduced vectors.

Source explanation

kernel/arm64/dot_kernel_sve.c
computes its two-vector and one-vector cutoffs as N & -(2*lanes)
and N & -lanes, where lanes comes from cntw or cntd.
This rounding method assumes a power-of-two lane count.

Call at VL384 Lanes Two-vector cutoff Full iteration Result
SDOT, N=11 12 11 & -24 = 8 24 elements 11 + 13*2 = 37
DDOT, N=5 6 5 & -12 = 4 12 elements 5 + 7*2 = 19

The nonzero cutoff enters a full two-vector iteration. The one-vector
cutoff is zero for each example, and the final tail has no active lanes.
Arithmetic division/remainder would avoid the count assumption, but no
source repair has been tested here. A64FX selects a different DOT kernel.

This is separate from #5917:
the failing path here is SVE loop-count calculation, rather than ASIMD
accumulator initialization. It is also separate from the SYRK/SYR2K
panel-split report #6100.

Hardware scope

The names above select OpenBLAS dispatch tables on QEMU's max CPU.
Documented maximum SVE lengths for the named processors are 128 bits for
Neoverse N2/V2, 256 bits for Neoverse V1, and 512 bits for A64FX
(Arm, NVIDIA).
SVE permits non-power-of-two multiples of 128 bits;
VL384 is an architectural conformance case supported by QEMU. These forced
table/VL combinations do not establish a failure on the named native
processors. Native confirmation is unavailable.

Reproduce

On Linux, use Git, GNU Make, host GCC, an AArch64 GCC cross toolchain
with its glibc sysroot, and QEMU user mode. GCC 15.2 was used for the
reported builds. Save the C block below as repro.c in a clean
working directory, then run these commands from that directory:

git init openblas-src
git -C openblas-src fetch --depth=1 https://github.com/OpenMathLib/OpenBLAS.git 277ef7801416412ee970873701fdf14d603d2c3f
git -C openblas-src checkout --detach FETCH_HEAD
cd openblas-src
make -j4 ARCH=arm64 BINARY=64 TARGET=ARMV8 DYNAMIC_ARCH=1 \
  'DYNAMIC_LIST=ARMV8SVE A64FX NEOVERSEV1 NEOVERSEN2' \
  NOFORTRAN=1 NO_LAPACK=1 USE_THREAD=0 NUM_THREADS=1 HOSTCC=gcc \
  CC=aarch64-linux-gnu-gcc AR=aarch64-linux-gnu-ar RANLIB=aarch64-linux-gnu-ranlib
make ARCH=arm64 BINARY=64 TARGET=ARMV8 DYNAMIC_ARCH=1 \
  'DYNAMIC_LIST=ARMV8SVE A64FX NEOVERSEV1 NEOVERSEN2' \
  NOFORTRAN=1 NO_LAPACK=1 USE_THREAD=0 NUM_THREADS=1 HOSTCC=gcc \
  CC=aarch64-linux-gnu-gcc AR=aarch64-linux-gnu-ar RANLIB=aarch64-linux-gnu-ranlib \
  PREFIX="$PWD/install" install
aarch64-linux-gnu-gcc -O2 -Wall -Wextra -Iinstall/include ../repro.c \
  install/lib/libopenblas.a -lm -lpthread -o dot-repro
OPENBLAS_CORETYPE=ARMV8SVE OPENBLAS_NUM_THREADS=1 \
  qemu-aarch64 -L /usr/aarch64-linux-gnu \
  -cpu max,sve-default-vector-length=48 ./dot-repro 384 s
OPENBLAS_CORETYPE=ARMV8SVE OPENBLAS_NUM_THREADS=1 \
  qemu-aarch64 -L /usr/aarch64-linux-gnu \
  -cpu max,sve-default-vector-length=48 ./dot-repro 384 d

The QEMU property is in bytes: 48 requests VL384.
Replacing qemu-aarch64 with QEMU 8.2.2's qemu-aarch64-static
repeats the comparison with the second emulator.
The program checks the actual vector length with PR_SVE_GET_VL and
prints the selected OpenBLAS core; confirm that the printed core matches
the requested dispatch table. Exit 0 means the checked values are right,
1 means a numerical mismatch, and 2 means a setup/argument
failure rather than a valid numerical result. Each mode makes one public
BLAS call.

repro.c
/* Public SDOT/DDOT one-call reproducer for a 384-bit SVE length. */
#include <cblas.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/prctl.h>

int main(int argc, char **argv) {
    int requested = argc > 1 ? atoi(argv[1]) : 384;
    int actual = prctl(51, 0, 0, 0, 0);
    if (actual < 0 || (actual & 65535) * 8 != requested) return 2;
    int isdouble = argc > 2 && !strcmp(argv[2], "d");
    int n = isdouble ? 5 : 11;
    float xf[128], yf[128];
    double xd[128], yd[128];
    for (int i = 0; i < 128; i++) {
        xf[i] = xd[i] = i < n ? 1 : 2;
        yf[i] = yd[i] = 1;
    }
    double got = isdouble ? cblas_ddot(n, xd, 1, yd, 1)
                          : cblas_sdot(n, xf, 1, yf, 1);
    int wrong = got != n;
    printf("DOT-VL: %s precision=%c core=%s VL=%d n=%d got=%g want=%d first_surfaced_by=differential\n",
           wrong ? "WRONG" : "RIGHT", isdouble ? 'd' : 's',
           openblas_get_corename(), requested, n, got, n);
    return wrong ? 1 : 0;
}

First surfaced by differential testing (first_surfaced_by: differential).

Lingua principale
C
Stelle
7.6k
Fork
1.7k
Merge medio
1g 19h
PR unite (30g)
53

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenMathLib/OpenBLAS

Tutte le issue di OpenMathLib/OpenBLAS

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.