incorrect usages of int for blasint with 64-bit API

[stevengj]

When I compile openblas with the 64-bit API, I get a lot of warnings about code which incorrectly assumes that blasint is the same as int.

There are dozens of warnings like:

gemv.c:202:48: warning: absolute value function 'abs' given an argument of type
      'blasint' (aka 'long') but has parameter of type 'int' which may cause
      truncation of value [-Wabsolute-value]
  if (beta != ONE) SCAL_K(leny, 0, 0, beta, y, abs(incy), NULL, 0, NULL, 0);

Maybe you need to define a BIABS(i) macro that expands to abs for the 32-bit API and labs (or llabs if needed) for the 64-bit API?

I also get a few other miscellaneous cases that use the wrong integer type:

lapack/laswp.c:100:8: warning: incompatible function pointer types passing 'int
      (*)(BLASLONG, BLASLONG, BLASLONG, float, float *, BLASLONG, float *,
      BLASLONG, blasint *, BLASLONG)' (aka 'int (*)(long, long, long, float,
      float *, long, float *, long, long *, long)') to parameter of type
      'int (*)()' [-Wincompatible-function-pointer-types]
                     laswp[flag], nthreads);
                     ^~~~~~~~~~~
../common_thread.h:180:39: note: passing argument to parameter 'function' here
                       void *c, BLASLONG ldc, int (*function)(), int threads);

lapack/zlaswp.c:99:80: warning: incompatible function pointer types passing 'int
      (*)(BLASLONG, BLASLONG, BLASLONG, float, float, float *, BLASLONG, float
      *, BLASLONG, blasint *, BLASLONG)' (aka 'int (*)(long, long, long, float,
      float, float *, long, float *, long, long *, long)') to parameter of type
      'int (*)()' [-Wincompatible-function-pointer-types]
  ...k1, k2, dummyalpha, a, lda, NULL, 0, ipiv, incx, laswp[flag], nthreads);
                                                      ^~~~~~~~~~~
../common_thread.h:180:39: note: passing argument to parameter 'function' here
                       void *c, BLASLONG ldc, int (*function)(), int threads);

1 warning generated.
xerbla.c:16:69: warning: format specifies type 'int' but the argument has type
      'blasint' (aka 'long') [-Wformat]
      fprintf(stderr, "Parameter %d to routine %s was incorrect\n", p, rout);

[brada4]

abs() can take any argument type, qwerty-abs() just own type.
As you notice it is a warning that code mifht be wrong, if you read manual then you understand code is correct.
If you try clang you get few more with fabs() in similar position.
PS i cleaned like 9/10ths of warnings recently.PR is welcome, but replacing one call with faux warning to 2-page ifdef system does not sound useful.

[martin-frbg]

Actually in a C context the two are different I think (though the likelyhood that the value of one of the increments actually overflows an int is going to be very low).

[brada4]

They dont overflow yet ... Leavins small chance to polish the code.

[stevengj]

As @martin-frbg said, C does not have overloading: abs, labs, llabs, fabs, fabsl, fabsf, and cabs are all different functions that take and return different types. If you call the wrong function, as is happening here (and in #1709), you run the risk of inadvertent truncation.

[brianborchers]

If someone is bothering to use the 64-bit interface, there is a good chance that they actually need it. It isn't too hard to create a situation where you'd get an overflow with a 32 bit signed integer parameter- just work with a vector of say 10 gigabytes of single precision floating point numbers. That's already 2.5 billion entries. One place that I've seen this cause problems is in using dcopy to copy a matrix or using daxpy to do a scaled matrix add.

[martin-frbg]

The labs issue should be fixed now, but I do not have a solution for the "incompatible function pointer types" problem (that is not related to INTERFACE64).

[brada4]

@stevengj posix-ly they are different but modern compilers tend to adapt shortest form to other types

[stevengj]

@brada4, what C compiler does this? Changing abs(x) to labs(x) changes the meaning of the program, so it is not a valid compiler optimization. Try the test program:

#include <stdio.h>
#include <stdlib.h>
int main(void) {
     long big = -2147483649;
     printf("abs(%ld) = %ld\n", big, (long) abs(big));
     return 0;
}

Both gcc 6.3.0 and clang (Apple LLVM version 9.1.0) correctly truncate the result to int rather than implicitly converting the call to labs, printingabs(-2147483649) = 2147483647.

[martin-frbg]

The function pointer issue can probably be masked by casting to (int(*),()) rather than just int(*), but I am not sure if this is actually a good idea. The underlying problem seems to be that the code equates a pointer to an array member with a pointer to a function, not sure if that is a healthy assumption. Anyone ?