Different function-signatures between some aliased LAPACK functions

[DenizBahadir]

Background information

In general, every LAPACK function has four names under which it can be called from C, which are all defined in header mkl_lapack.h:

An all uppercase version, an all lowercase version, an all uppercase version with a trailing underscore and an all lowercase version with a trailing underscore.

Besides these, there also exist similar 64-integer versions with all uppercase or all lowercase names that have "_64" appended.

Problem

I noticed, that some of these function tuples have different function signatures although they should just be aliases of each other, which leads to compiler errors due to non-matching parameter-types (when trying the different function aliases with the exact same type of parameters).

In particular, the following functions differ in their function signature compared to their aliases.

• SGEJSV: Its second parameter "jobu" is missing the const keyword. Its alias functions all have a const parameter "jobu".
• SGEJSV_64: Same error as for SGEJSV.
• CLAQZ0: Its first three parameters "wants", "wantq" and "wantz" are of type const char* while its three alias functions define them as const MKL_INT*. According to the LAPACK documentation at netlib.org const char* seems to be correct. So the three alternatives are wrong.
• CLAQZ0_64 / claqz0_64: Here the first three parameters are of type const MKL_INT64*. These should probably also be of type const char* instead!?
• ZLAQZ0: The same comment as for CLAQZ0 applies here.
• ZLAQZ0_64 / zlaqz0_64: The same comment as for CLAQZ0_64 / claqz0_64 applies here.
• ZLAQZ1: The four parameters "a", "b", "q" and "z" are of type MKL_Complex8* while its three alias functions define them as MKL_Comples16*. According to the LAPACK documentation at netlib.org MKL_Complex16* seems to be correct. So the three alternatives are correct.

Additional information

I am seeing this problem with MKL 2022.1.0.

[ShanmukhS_Intel]

Hi,

Thank you for posting on Intel communities.

I noticed, that some of these function tuples have different function signatures although they should just be aliases of each other, which leads to compiler errors.

>> Could you please let us know what sort of compiler errors were faced by you?

Do you mean you are getting compiler errors (like type miss-match) when calling a function with it's alias name?

Best Regards,

Shanmukh.SS

Best Regards,

Shanmukh.SS

[DenizBahadir]

I noticed, that some of these function tuples have different function signatures although they should just be aliases of each other, which leads to compiler errors.

>> Could you please let us know what sort of compiler errors were faced by you?

Do you mean you are getting compiler errors (like type miss-match) when calling a function with it's alias name?

Exactly. (To be precise, these are warnings, but as I am treating warnings as errors, these are compiler errors for me.)

For example:

Assume, I have a wrapper-function around CLAQZ0 which is defined like this:

#include <mkl_lapack.h>

/* My_CLAQZ0 has the same signature as CLAQZ0! */
void My_CLAQZ0( const char* wants, const char* wantq, const char* wantz, const MKL_INT* n,
                const MKL_INT* ilo, const MKL_INT* ihi, MKL_Complex8* a, const MKL_INT* lda,
                MKL_Complex8* b, const MKL_INT* ldb, MKL_Complex8* alpha, MKL_Complex8* beta,
                MKL_Complex8* q, const MKL_INT* ldq, MKL_Complex8* z, const MKL_INT* ldz,
                MKL_Complex8* work, const MKL_INT* lwork, float* rwork, const MKL_INT* rec,
                MKL_INT* info)
{
    #if defined(WRAP_CLAQZ0)
        return CLAQZ0( wants, wantq, wantz, n,
                       ilo, ihi, a, lda,
                       b, ldb, alpha, beta,
                       q, ldq, z, ldz,
                       work, lwork, rwork, rec,
                       info );
    #elif defined(WRAP_claqz0)
        return claqz0( wants, wantq, wantz, n,
                       ilo, ihi, a, lda,
                       b, ldb, alpha, beta,
                       q, ldq, z, ldz,
                       work, lwork, rwork, rec,
                       info );
    #else
        #error "Either define WRAP_CLAQZ0 or WRAP_claqz0!"
    #endif
}

If you try to compile this with WRAP_CLAQZ0 defined everything compiles.

If, however, you try to compile this with WRAP_claqz0 defined, you will get errors as the following ones (which came from Clang 12):

$> clang-12 -Werror -Wall -c My_CLAQZ0.c -I /opt/intel/oneapi/mkl/2022.1.0/include -DWRAP_claqz0

My_CLAQZ0.c:18:24: error: incompatible pointer types passing 'const char *' to parameter of type 'const int *' [-Werror,-Wincompatible-pointer-types]
        return claqz0( wants, wantq, wantz, n,
                       ^~~~~
/opt/intel/oneapi/mkl/2022.1.0/include/mkl_lapack.h:11520:29: note: passing argument to parameter 'wants' here
void claqz0( const MKL_INT* wants, const MKL_INT* wantq, const MKL_INT* wantz, const MKL_INT* n,
                            ^
My_CLAQZ0.c:18:31: error: incompatible pointer types passing 'const char *' to parameter of type 'const int *' [-Werror,-Wincompatible-pointer-types]
        return claqz0( wants, wantq, wantz, n,
                              ^~~~~
/opt/intel/oneapi/mkl/2022.1.0/include/mkl_lapack.h:11520:51: note: passing argument to parameter 'wantq' here
void claqz0( const MKL_INT* wants, const MKL_INT* wantq, const MKL_INT* wantz, const MKL_INT* n,
                                                  ^
My_CLAQZ0.c:18:38: error: incompatible pointer types passing 'const char *' to parameter of type 'const int *' [-Werror,-Wincompatible-pointer-types]
        return claqz0( wants, wantq, wantz, n,
                                     ^~~~~
/opt/intel/oneapi/mkl/2022.1.0/include/mkl_lapack.h:11520:73: note: passing argument to parameter 'wantz' here
void claqz0( const MKL_INT* wants, const MKL_INT* wantq, const MKL_INT* wantz, const MKL_INT* n,
                                                                        ^
3 errors generated.

[ShanmukhS_Intel]

Hi,

Thank you for pointing out and sharing the findings.

We are working on your issue internally. We'll get back to you soon with an update.

Best Regards.

Shanmukh.SS

[Gennady_F_Intel]

the issues you reported here were escalated and would be fixed into one of the next releases/updates. The thread will keep updated.

Thanks

[DenizBahadir · Accepted solution]

It seems as if this issue is fixed by MKL 2023.0.0.

Thank you!