xxhash 0.8.1 fails to compile on RHEL 7 ppc64le #622

New issue

Closed

opened 2021-11-29 18:22:24 -06:00 by ellert · 2 comments

ellert commented

2021-11-29 18:22:24 -06:00

(Migrated from github.com)

The compilation error is:

In file included from xxhash.c:43:0:
xxhash.h: In function 'XXH3_accumulate_512_vsx':
xxhash.h:4148:9: error: invalid parameter combination for AltiVec intrinsic
         xxh_u64x2 acc_vec        = vec_xl(0, xacc + 2 * i);
         ^
xxhash.h:4158:9: error: invalid parameter combination for AltiVec intrinsic
         vec_xst(acc_vec, 0, xacc + 2 * i);
         ^
In file included from xxhash.c:43:0:
xxhash.h: In function 'XXH3_accumulate_512_vsx':
xxhash.h:4148:9: error: invalid parameter combination for AltiVec intrinsic
         xxh_u64x2 acc_vec        = vec_xl(0, xacc + 2 * i);
         ^
xxhash.h:4158:9: error: invalid parameter combination for AltiVec intrinsic
         vec_xst(acc_vec, 0, xacc + 2 * i);
         ^
make: *** [libxxhash.so.0.8.1] Error 1
make: *** Waiting for unfinished jobs....
make: *** [xxhash.o] Error 1

Full log: https://koji.fedoraproject.org/koji/taskinfo?taskID=79410933

This failure is related to the use of altivec functions vec_xl and vec_xsl.
RHEL 7 uses gcc 4.8.5.
xxhash 0.8.0 and earlier versions compile on RHEL7 ppc64le.
If I revert the commit b40bf8dc by @mpe that introduces the use of vec_xl and vec_xsl the compilation succeeds.

The compilation error is: ``` In file included from xxhash.c:43:0: xxhash.h: In function 'XXH3_accumulate_512_vsx': xxhash.h:4148:9: error: invalid parameter combination for AltiVec intrinsic xxh_u64x2 acc_vec = vec_xl(0, xacc + 2 * i); ^ xxhash.h:4158:9: error: invalid parameter combination for AltiVec intrinsic vec_xst(acc_vec, 0, xacc + 2 * i); ^ In file included from xxhash.c:43:0: xxhash.h: In function 'XXH3_accumulate_512_vsx': xxhash.h:4148:9: error: invalid parameter combination for AltiVec intrinsic xxh_u64x2 acc_vec = vec_xl(0, xacc + 2 * i); ^ xxhash.h:4158:9: error: invalid parameter combination for AltiVec intrinsic vec_xst(acc_vec, 0, xacc + 2 * i); ^ make: *** [libxxhash.so.0.8.1] Error 1 make: *** Waiting for unfinished jobs.... make: *** [xxhash.o] Error 1 ``` Full log: https://koji.fedoraproject.org/koji/taskinfo?taskID=79410933 This failure is related to the use of altivec functions vec_xl and vec_xsl. RHEL 7 uses gcc 4.8.5. xxhash 0.8.0 and earlier versions compile on RHEL7 ppc64le. If I revert the commit b40bf8dc by @mpe that introduces the use of vec_xl and vec_xsl the compilation succeeds.

👍 1

Cyan4973 commented

2021-11-29 21:02:26 -06:00

(Migrated from github.com)

I believe @mpe complained that the previous altivec variant was not compiling properly on newer gcc versions.
So it seems we can't have something that's fine for all versions of gcc ?

Another opened question is : should we test PPC64LE + gcc v4.8.5 in CI ? and is that even possible btw ?

I believe @mpe complained that the previous altivec variant was _not_ compiling properly on newer `gcc` versions. So it seems we can't have something that's fine for all versions of `gcc` ? Another opened question is : should we test `PPC64LE` + `gcc v4.8.5` in CI ? and is that even possible btw ?

t-mat commented

2021-11-30 00:12:47 -06:00

(Migrated from github.com)

Another opened question is : should we test PPC64LE + gcc v4.8.5 in CI ?

I'd like to rephrase the question as : Should we complete our variant test matrix of gcc versions and architectures in CI?
The matrix will cover 48 variants in total

8 versions of gcc (4.8, 5, 6, 7, 8, 9, 10, 11)
6 architectures (arm, aarch64, PPC64, PPC64LE, S390X, MIPS)

My personal answer is yes.
For major compilers/architectures/platforms, our test should catch basic errors.

and is that even possible btw ?

As for gcc-5 and greater, it seems we can do it easily. Because apt-get provides GCC cross compiler packages.

So far, I'm not sure about gcc-4.8 cross compiler. I'll try to find the package of it.

> Another opened question is : should we test PPC64LE + gcc v4.8.5 in CI ? I'd like to rephrase the question as : Should we complete our variant test matrix of `gcc` versions and architectures in CI? The matrix will cover 48 variants in total - 8 versions of `gcc` (`4.8`, `5`, `6`, `7`, `8`, `9`, `10`, `11`) - 6 architectures (`arm`, `aarch64`, `PPC64`, `PPC64LE`, `S390X`, `MIPS`) My personal answer is yes. For major compilers/architectures/platforms, our test should catch basic errors. > and is that even possible btw ? As for `gcc-5` and greater, it seems we can do it easily. Because `apt-get` provides [GCC cross compiler packages](https://github.com/lz4/lz4/runs/4326637792?check_suite_focus=true#step:13:8). So far, I'm not sure about `gcc-4.8` cross compiler. I'll try to find the package of it.

👍 1

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Cyan4973/xxHash#622

No description provided.

Rows
Columns