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

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]));
}

Start with the reproducer in the issue and inspect cgemv_t.S and zgemv_t.S, with zgemv.c as the mentioned workaround location. Verify the failure when the buffer contains NaN or Inf values, then confirm that the same cgemv_ call produces non-NaN results without requiring a caller-side memset.