The optional NaN checks performed by LAPACKE front-ends computed array
offsets and lengths in 32-bit lapack_int arithmetic, which overflows for
large matrices (e.g. LAPACKE_dpotrf with n = lda >= 46341 overflows
j*lda in LAPACKE_dtr_nancheck, leading to out-of-bounds reads and
crashes). Several nancheck helpers (ge, gb, tp, tf) already cast to
size_t; this applies the same treatment to the ones that were missed:
- ?tr_nancheck: cast a[i+j*lda] index to size_t (also covers po/sy/he
checks, i.e. the POTRF/Cholesky path)
- ?_nancheck (vector): iterate by element count instead of n*inc, with
size_t indexing
- ?sp/?pp/?pf/?hp/?tp/?tf_nancheck: compute n*(n+1)/2 length in size_t
- ?tz_nancheck: widen the part offsets to int64_t (keeping the -1
sentinel) and compute them with a widening cast
Verified with UBSan: LAPACKE_str_nancheck at n = lda = 47000 previously
reported signed integer overflow and crashed with SEGV at -O0; it now
passes and still detects the NaN. Old and new code produce identical
results across 1907 enumerated small-size cases (all layouts, uplo,
diag, shapes and NaN positions for tr/tz/vector/packed variants).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Corrected the register constraints for the PowerPC dcbt (Data Cache Block
Touch) instruction in Power10 kernel implementations. The dcbt instruction
has special behavior where if the first operand (RA) is r0, it uses the
value 0 instead of the register contents. Therefore, RA must use the "b"
constraint (any GPR except r0), while RB can use "r" (any GPR including r0).
Changes:
- Changed first operand constraint from "r" to "b" to exclude r0
- Changed second operand constraint from "b" to "r" for flexibility
This ensures correct prefetch behavior and compliance with PowerPC ISA
specifications, preventing potential issues where r0 might be incorrectly
used as the base address register.
Signed-off-by: Amrita H S <amritahs@linux.vnet.ibm.com>
Replace normal vector pair pointer dereferences with the optimized
__builtin_vsx_lxvp builtin across DGEMM, ZGEMM, and DGEMV kernels.
Also done some identation corrections in dgemm_kernel_power10.c.
This is done as part of POWER code cleanup and may not have any
performance impact.
Signed-off-by: Amrita H S <amritahs@linux.vnet.ibm.com>
On Apple, the shared library link rule for Fortran used GCC-specific flags:
-x f95-cpp-input (GCC preprocessing flag; NAG does not support it)
-Wl,-shared (Linux linker flag; macOS needs -dynamiclib)
The fix is NAG-specific — other non-GNU compilers (Intel, flang, Cray,
etc.) are left alone since they may handle the existing code paths fine.
Fix in two places (both already inside if(APPLE) / if(APPLE AND BUILD_STATIC_LIBS)):
1. Before add_library() (affects the main CMake Fortran shared lib rule):
For NAG Fortran, substitute CMAKE_C_CREATE_SHARED_LIBRARY so the
C compiler link rule is used instead.
2. Inside the APPLE AND BUILD_STATIC_LIBS block (the static->shared
conversion trick for long argument lists): add an elseif(NAG) branch
that uses the C compiler with -dynamiclib and auto-detects the NAG
Fortran runtime (libf72rts) from the compiler's directory so that
NAGf90_* symbols resolve.
Tested with NAG 7.2.7243 on macOS/arm64.
Add a RISC-V subsection to docs/install.md inside 'Building from source',
between the existing MIPS and FreeBSD sections, covering:
- Target selection table (RISCV64_GENERIC / RISCV64_ZVL128B /
RISCV64_ZVL256B / C910V / x280) and what each is for.
- The general property that GENERIC / ARCH_GENERIC targets across
all architectures map to the non-vectorized plain-C reference
path, with the Makefile.riscv64 scalar -march override noted as
the RISC-V-specific compounding factor.
- GCC 14+ requirement for the ZVL targets on current OpenBLAS
releases (GCC 13 does not implement the __riscv_vsseg* intrinsics
used by the _rvv.c kernels and falls back to scalar silently,
detectable only by disassembly).
- Reference objdump-based verification command and expected
opcode-count range for a correct RISCV64_ZVL128B build.
README.md now keeps a single one-line pointer to the new install.md
section at the spot where users encounter the RISC-V build commands,
so the signposting is preserved without bloating the page that GitHub
renders by default.
v2 of this PR, addresses review feedback from @martin-frbg on
relocation and on the broader GENERIC framing.
Co-authored-by: Vaibhav805 <Vaibhav805@users.noreply.github.com>
Martin Kroeker