Possible bug in magmablas_dswap [MAGMA 1.1.0 and 1.2*]

[jgpallero]

Hello:

Attached I send a simple testing program for magmablas_dswap. I think that the function has several bugs.

First of all, if I try to use magmablas_dswap with increments equals zero or positive in vector x and y, tha result is that the vector x is copied into y but y is not changed to x, so the result is x in x and x in y.

Second, if I try to operate with increments equals -1, an error CUBLAS_STATUS_MAPPING_ERROR occurs (code error 11 in cublas_api.h).

This tests can be done in the attached file changing the value of the variable 'incCalc' in order to try differents increments (-1, 0, 1)

Cheers

PS: I'm using CUDA 4.1 and gcc 4.6.3 from Debian Sid

[jgpallero]

Hello again:

The reported bug in magmablas_dswap is presented in magma 1.2.1 too

Cheers

[Stan Tomov]

Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan

[jgpallero]

Hello,
I think the bug is actually in the example file, in particular, you have used expressions like sizeof(x1), which in your case is 32 (4 doubles), instead of sizeof(x[0]) or just sizeof(double).
Stan

You are right (partially). I have changed the sizeof calls to sizeof(double), but I have two problems.

1- When the increment between the elements of the vectors is 0, the reference BLAS does no computations, so the output vectors are the same than the input ones. But MAGMA swaps the two first elements x[0] and y[0] and does no operations with the remaining. I think that the behavior should be the same as in reference BLAS for increments equals 0, so I think that this is a bug in MAGMA

2- When the increments are -1 I obtain an cublasGetVector error, status=11. I think that all the code is correct and I suspect a bug too.

Attached I send the new fixed test_dswap.c code (only the incCalc=*; line is need to change)

Cheers

[mgates3]

incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.

I agree that negative increments are not handled by the current MAGMA BLAS dswap code.

Note that the cublasDswap routine works correctly for negative increments, so I recommend using that one. (The MAGMA BLAS dswap routine probably dates from a time before CUBLAS was fully implemented.)

-mark

[jgpallero]

incx = 0 is an error condition; you are not passing a vector. Most of the BLAS routines such as DGEMV explicitly state that INCX must not be zero. The CPU implementation actually DOES swaps of the first element, but for even n, it does an even number of swaps, so the end result is the same. Try with n=3 to see that the first element is swapped. Nonetheless, the user should not call dswap with incx=0 or incy=0.

But in my tests with magma_dswap() the first element is always interchanged, with N odd or even. Although incX and incY are wrong values I think that reproduce the same results as the reference netlib BLAS is a good feature