Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Case-sensitive core-name check in #6027 disables AMD AVX-512 block-size override

Open Beginner friendly
  • Is something wrong?
#6,192 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
performance

Research direction

Start with the guard in kernel/setparam-ref.c around line 2135 and compare its core-name strings with the names returned in driver/others/dynamic.c around line 1025. The issue provides a minimal correction and a block_probe.c reproduction; build and run it with OPENBLAS_CORETYPE=SkylakeX and Haswell. Done when the SkylakeX block sizes are restored and the Haswell values remain unchanged.

Written by the indexing model from the issue text.

Description

Summary

The core-name guard added by #6027 uses case-sensitive strcmp against lowercase names, while gotoblas_corename() returns mixed-case names. Consequently, the AMD AVX-512 block-size override is skipped even for the intended cores.

This is still present in develop at 40fa0ead64f2:

This report concerns block-size initialization. Kernel selection still reports SkylakeX. I have not measured a performance regression or speedup.

Controlled native comparison

Host: AMD Ryzen 5 7500F (Zen 4), Windows 11 x64. GCC 16.2.0 from w64devkit 2.10.1; ILP64, DYNAMIC_ARCH, actual runtime thread count 1.

Three builds used the same source baseline, compiler and options:

  • A: #6027's first parent, 78501e395e86efdf9397234f162e9403b363616e.
  • B: A plus exactly #6027, equivalent to merge commit e5a25b7afa4f9d40916039ba34b753c6b70039a0.
  • C: B with only the three string literals corrected to their actual capitalization.
Build Haswell DGEMM P/Q SkylakeX DGEMM P/Q Haswell access violations / 26 cases
A 512 / 512 512 / 512 23 / 26
B 512 / 128 192 / 384 0 / 26
C 512 / 128 512 / 512 0 / 26

Thus #6027 fixes the Haswell crash in this experiment, while the capitalization correction separately restores the intended SkylakeX block sizes and preserves the Haswell fix.

SHA-256 comparison of 3,204 object files found only the five kernel/setparam_*.obj files changed in each transition. The test program object was identical across all three binaries. The only original source file changed was kernel/setparam-ref.c.

Minimal block-size reproduction

Save this as block_probe.c in the source root. It uses internal headers to observe initialization directly:

#include <stdio.h>
#include "common.h"
#include "cblas.h"
extern void gotoblas_dynamic_init(void);
int main(void) {
    gotoblas_dynamic_init();
    openblas_set_num_threads(1);
    printf("core=%s P=%d Q=%d threads=%d\n", openblas_get_corename(),
           gotoblas->dgemm_p, gotoblas->dgemm_q, openblas_get_num_threads());
    return 0;
}

From a clean source checkout at B, with w64devkit's bin on PATH, the options used in the experiment are below (PowerShell). Run libs and netlib sequentially:

$opts = @(
  'BINARY=64', 'DYNAMIC_ARCH=1',
  'DYNAMIC_LIST=PRESCOTT NEHALEM SANDYBRIDGE HASWELL SKYLAKEX',
  'TARGET=PRESCOTT', 'USE_THREAD=1', 'NUM_THREADS=64', 'USE_OPENMP=0',
  'NO_AFFINITY=1', 'NO_SHARED=1', 'NO_LAPACKE=1',
  'BUILD_SINGLE=1', 'BUILD_DOUBLE=1', 'INTERFACE64=1',
  'COMMON_OPT=-O2 -march=x86-64 -mtune=generic -fno-asynchronous-unwind-tables',
  'FCOMMON_OPT=-O2 -march=x86-64 -mtune=generic -fno-asynchronous-unwind-tables -frecursive -fdefault-integer-8 -fallow-argument-mismatch'
)
make -j8 libs @opts
make -j8 netlib @opts
gcc -O2 -march=x86-64 -fno-asynchronous-unwind-tables -I. -DDYNAMIC_ARCH -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DSMP_SERVER -DSMALL_MATRIX_OPT -DMS_ABI block_probe.c libopenblasp-r0.3.34.dev.a -lpthread -lm -o block_probe.exe
$env:OPENBLAS_NUM_THREADS = '1'
$env:OPENBLAS_CORETYPE = 'SkylakeX'
.\block_probe.exe
$env:OPENBLAS_CORETYPE = 'Haswell'
.\block_probe.exe

No OPENBLAS_L2_SIZE override was set for these two runs. The build used the C-translated LAPACK backend. The probe's feature macros must match the library build because it reads gotoblas_t.

On this host, B prints:

core=SkylakeX P=192 Q=384 threads=1
core=Haswell P=512 Q=128 threads=1

Apply the literal-only correction below, rebuild and relink with the same options. C prints:

core=SkylakeX P=512 Q=512 threads=1
core=Haswell P=512 Q=128 threads=1

This reduced probe was also compiled and run against all three experiment libraries.

Candidate correction
-      if (strcmp(gotoblas_corename(), "cooperlake") == 0 || strcmp(gotoblas_corename(), "skylakex") == 0 || strcmp(gotoblas_corename(), "sapphirerapids") == 0) {
+      if (strcmp(gotoblas_corename(), "Cooperlake") == 0 || strcmp(gotoblas_corename(), "SkylakeX") == 0 || strcmp(gotoblas_corename(), "SapphireRapids") == 0) {
Additional validation and scope

Each build ran 156 independent-process cases: six configurations (automatic, Haswell, Zen, SkylakeX, Sandybridge, and Haswell with L2 override 2048), each with DGEMM 256×K @ K×256 for K=128,160,176,256,300,340,512,1024 repeated three times, plus symmetric positive-definite DSYEVD at N=300 and 1240.

B and C both passed 156/156. DGEMM was checked against independent scalar dot products, and DSYEVD against an independently computed full AV−VΛ residual. Across passing cases of the three builds, maximum DGEMM absolute error was 1.43e-13 and maximum eigen residual relative to the matrix Frobenius norm was 1.77e-15 (rounded upward).

Automatic dispatch selected SkylakeX; Zen requests mapped to Haswell in this DYNAMIC_LIST. Cooperlake and SapphireRapids were not separate kernels in this build, so their capitalization mismatch is source evidence, not a claim of native testing for those kernels. This was a static native OpenBLAS comparison, not three rebuilt NumPy wheels. No performance claim is made.

Investigation, local patch preparation and test execution were assisted by Codex.

Dominant language
C
Stars
7.7k
Forks
1.7k
Avg merge
1d 8h
Merged PRs (30d)
60

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenMathLib/OpenBLAS

All issues in OpenMathLib/OpenBLAS

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.