[z|c]gemv assume no inf or nan in buffer on x86_64

[jeromerobert]

cgemv_t.S and zgemv_t.S return wrong results when the buffer contains NaN or Inf values. I guess that somewhere it assume that 0 * buffer[i] = 0 without initializing buffer[i]. The buffer may contains NaN or Inf values because of previous OpenBLAS functions calls.

Any easy workaround would be to memset the buffer in zgemv.c but IMHO it should be fixed in the assembler code (which I'm not able to do). Here is a simple program which reproduce the issue.

#include <math.h>
#include <assert.h>
#include <stdlib.h>

// OpenBLAS private API used to simulate a previous function call which add a NaN to the buffer
void * blas_memory_alloc(int);
void blas_memory_free(void*);

int main(void) {
    int size = 59;
    int size2 = 50;
    float v = 1;
    int one = 1;
    float * buffer = (float *)blas_memory_alloc(1);
    for(int i = 0; i < 256; i++)
        // also work with buffer[i] = 1./0;
        buffer[i] = sqrt(-1);
    blas_memory_free(buffer);
    float * A = calloc(size * size, 2 * 4);
    float * y = calloc(size, 2 * 4);
    float * x = calloc(size, 2 * 4);
    for(int i = 0; i < 2*size*size; i++)
        A[i] = i;
    for(int i = 0; i < 2*size; i++) {
        y[i] = i;
        x[i] = i;
    }
    cgemv_("T", &size, &size2, &v, A, &size, x, &one, &v, y, &one);
    for(int i = 0; i < 2 * size; i++)
        assert(!isnan(y[i]));
}

[martin-frbg]

Possibly related to #695
Hmm. Apparently not, at least copying that memset into gemv.c and zgemv.c did not change the outcome of the testcase from 695 (while substituting the C implementation of cgemv_t did). Sorry for the noise here.