cdotu_ returning 0s and segfault

[epiper-rv]

My C++ code:

#include <iostream>
#include <complex>
#include <cblas.h>

extern "C" void cdotu_(std::complex<float> *res, int *n, 
                    const std::complex<float> *x, int *incx, 
                    const std::complex<float> *y, int *incy);

int main() {
    int n = 3;
    int incx = 1;
    int incy = 1;

    std::complex<float> x[] = { {1.0f, 2.0f}, {3.0f, 4.0f}, {5.0f, 6.0f} };
    std::complex<float> y[] = { {7.0f, 8.0f}, {9.0f, 10.0f}, {11.0f, 12.0f} };
    std::complex<float> result;

    for (int i = 0; i < n; ++i){
        std::cout << "x: " << x[i] << ", y: " << y[i] << "\n";
    }

    cdotu_(&result, &n, x, &incx, y, &incy);

    std::cout << "Result of cdotu_: " << result << '\n';
    return 0;
}

Result:

x: (1,2), y: (7,8)
x: (3,4), y: (9,10)
x: (5,6), y: (11,12)
Result of cdotu_: (0,0) # The error

The correct answer should be: (-39,214) which works when I call cblas_cdotu_sub instead of cdotu_.

One other interesting thing. If I change:

- std::complex<float> result;
+ std::complex<float> result = {1.0f, 1.0f};

I get a segfault:

x: (1,2), y: (7,8)
x: (3,4), y: (9,10)
x: (5,6), y: (11,12)

Thread 1 "cdotu_repro" received signal SIGSEGV, Segmentation fault.
0x000073df245f5c40 in cdotu_k_SKYLAKEX () from /lib/libopenblas.so.0

I made a similar simple program using sdot_, and that worked as intended.

Compile Command:

g++ -o cdotu_repro cdotu_repro.cpp -lopenblas

Enviorment information:

OS: Ubuntu 24.04.2 LTS (x86_64)
G++ version: 13.3.0
OpenBLAS version: 0.3.30 (release)
CPU: Intel(R) Xeon(R) Gold 6246R CPU @ 3.40GHz

This is a Cascade Lake CPU, which is not listed directly as a supported CPU. Is this why the test does not work? But then why does the cblas_cdotu_sub work and not cdotu_? Or am I calling it incorrectly?

I found this issue when building PyTorch with OpenBLAS. The repro above shows how PyTorch calls cdotu_.

[martin-frbg]

that's probably an argument error in your call, I'll have a look at it later. Generally the cblas_ function interfaces are specifically intended for calling BLAS from C/C++ while the non-prefixed ones expect Fortran-like argument conventions (because the original reference implementation is written in Fortran)

[martin-frbg]

Cascade Lake not being listed as a unique build target is not a problem, given that it is mostly a refresh of Sky Lake with no significant instruction set changes relevant to OpenBLAS

[isuruf]

See pytorch/pytorch#143846