I'm working on AIX with IBM's XL C compiler. I'm catching a compile error and I'm not sure how to proceed:
$ xlc -g3 -O0 -qarch=pwr8 -qaltivec fips197-p8.c -o fips197-p8.exe
"fips197-p8.c", line 59.16: 1506-754 (W) The parameter type is not valid for a function of this linkage type.
The relevant source code is shown below. The complete source code is available at fips197-p8.c
. The source code is a test driver for Power 8 __cipher
and __vcipherlast
. It has a main and a few C functions. Effectively is a minimal complete working example for Power 8 AES.
$ cat -n fips197-p8.c
...
11 #if defined(__xlc__) || defined(__xlC__)
12 // #include <builtins.h>
13 #include <altivec.h>
14 typedef vector unsigned char uint8x16_p8;
15 typedef vector unsigned int uint64x2_p8;
16 #else
17 #include <altivec.h>
18 typedef vector unsigned char uint8x16_p8;
19 typedef vector unsigned long long uint64x2_p8;
20 #endif
...
52 uint8x16_p8 Load8x16(const uint8_t src[16])
53 {
54 #if defined(__xlc__) || defined(__xlC__)
55 /* IBM XL C/C++ compiler */
56 # if defined(__LITTLE_ENDIAN__)
57 return vec_xl_be(0, src);
58 # else
59 return vec_xl(0, src);
60 # endif
61 #else
62 /* GCC, Clang, etc */
63
64 #endif
65 }
The compiler version is shown below. We don't control the compiler, so this is what we have:
$ xlc -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0000
vec_xl
is fine on a little-endian. vec_xl
for big-endian is giving us the trouble.
What is the problem, and how do I fix it?
So a little guesswork (confirmed by OP comments since it works) led me to think that this cryptic & obscure "The parameter type is not valid for a function of this linkage type." message (google first match is this question !) could be a qualifier issue.
Since your contract is
it is possible that, given the options & the current endianness, the compiler/prototype believes that
vec_xl_be
expects a non-const parameter assrc
.So passing a
const
violates the contract (and that's the nicest wayxlc
could find to notifu you)So either change to
(with the risk of dropping constant constraints for all callers)
or drop the
const
by a non-const cast (like we do when the prototype lacksconst
, but the data is in fact not modified in the function):