OpenBLAS 0.3.29: Failure to build for powerpc64le with GCC 6 and 7

[giordano]

https://buildkite.com/julialang/yggdrasil/builds/16321#01945b31-3e77-4ddf-bc39-21d0fbd0a596/6-3603

[16:37:10] ../kernel/power/gemm_common.c:81:10: error: incompatible types when returning type ‘int’ but ‘vec_bf16 {aka __vector(8) short unsigned int}’ was expected
[16:37:10]    return vec_xl_len(src2, n * sizeof(IFLOAT));
[16:37:10]           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[16:37:10] ../kernel/power/gemm_common.c: In function ‘vec_storeN’:

Used to work in OpenBLAS 0.3.28.

[rgommers]

Is there a reason to use a GCC version that old? Compilers that old tend to have a lot of SIMD-related bugs and missing features, and are only shipped on distro versions that are well beyond their EOL I'd expect.

I'm not sure if there's a defined minimum supported GCC version (that'd be interesting to know), but from a quick browse it seems nothing that old is tested in CI.

[martin-frbg]

README.md states
Please use GCC version 11 and above to compile OpenBLAS on the POWER architecture
(since some relatively recent discussion with the IBM team)

[giordano]

Is there a reason to use a GCC version that old?

Supporting users on old systems which don't have libgfortran5 🙂

README.md states
Please use GCC version 11 and above to compile OpenBLAS on the POWER architecture
(since some relatively recent discussion with the IBM team)

Any chance of disabling the new features with an old compilers? The alternative would be to completely throw off support for libgfortran3 and 4 users.

[giordano]

Side note, the change in the requirements of compiling the package wasn't mentioned in the release notes.

[martin-frbg]

Honestly I did not expect anybody to still use such an old compiler (which would most likely result in other errors even if that one PR was reverted). Is there a sizable user base who is actually caught up in this (can't install a newer GCC even locally in their unprivileged account) ? (I guess you could use NOFORTRAN=1 to build with the f2c-converted LAPACK ~3.9 and avoid the libgfortran dependency altogether, but I am not sure how well the result would play with code built by gcc6)
Setting BUILD_BFLOAT16=0 should work around this one issue by disabling all BF16 support, but as stated there are likely to be several other recent codes that cannot be built with a GCC last updated six years ago and no longer supported by its developers

[giordano]

Is there a sizable user base who is actually caught up in this

Red Hat 7, which comes with GCC 4.9, is still on Extended Life Cycle Support for 3 more years, and Red Hat 8, which comes with GCC 8, will still be maintained until 2029 (with Extended Life Cycle Support until 2032). For what is worth, clusters in my institute are still on Red Hat 7, although they're jumping soon to v9, also, they're x86_64 so I don't personally care about this specific issue.

Alright, I guess we'll stop building OpenBLAS for libgfortran 3 and 4 on powerpc64 and move on, thanks for the prompt reply.

[martin-frbg]

I'm not that familiar with RHEL, but I remember a "devtoolset" package being mentioned whenever the topic of installing more recent gcc versions came up. Not sure if that is still valid and/or would suffice to get you to gcc11 at least

[rgommers]

Yep, devtoolset works fine, and is what you'd normally use I think (it's certainly used for Python packaging on Linux to support old distro versions).