aarch64 compiler version cannot build numpy, bug is fixed upstream

[mattip]

When building NumPy with the manylinux2014 image, I get a compiler error. How can we report issues to http://bugzilla.redhat.com/bugzilla?

The file badfile.c is a reproducer.

I don't know how to report this since it needs to be reported to redhat. Do we have a way to report issues to them?

[isuruf]

@jayfurmanek, nvm, this is an arm64 issue

[isuruf]

See conda-forge/numpy-feedstock#138 (comment) for a small testcase. @jjhelmus, do you know if this was reported?

I checked and this error is in gcc 8.2. https://godbolt.org/z/d7qkA6

[jjhelmus]

@jjhelmus, do you know if this was reported?

I reported the issue and it was fixed upstream in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075

[mattip]

I am not familiar with the redhat release cycle. This was fixed in 2019-04-30 but is still not available in the compilers used in the manylinux2014 image:

$ cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)

$gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)

$ which gcc
/opt/rh/devtoolset-8/root/usr/bin/gcc

[mattip]

It seems if we enable the testing stream and install devtoolset-9 compilation runs to completion. The glibc 2.17 version (used in redhat 7.7.1908, in manylinux2014) of complex math routines are inaccurate. This trips a blacklist of these functions in NumPy. Unfortunately, the replacement np.arcsinh also seems inaccurate on aarch64 with gcc (GCC) 9.1.1 20190605.

It may be more straightforward to start a branch to use a PEP 600 manylinux_2_18 image to avoid these problems, see also ppc64le problems with NumPy and pre-2.18 glibc trig functions. Do we know

• if wheel, pip support PEP 600?
• how popular glibc2.17-based systems are for other hardware like aarch64, ppc64le ?

[jayfurmanek]

• how popular glibc2.17-based systems are for other hardware like aarch64, ppc64le ?

Since glibc2.17 is in RHEL7 and in the new manylinux2014, I'd say it's where most of the user base is at the moment, unfortunately.

[mayeut]

@mattip,
images were updated to use devtoolset-9.
It should fix the build issue. Is the accuracy issue on np.arcsinh really related to this gcc version ? If not I guess we can close this issue. I guess back porting the incriminating trig functions from a more recent glibc is a no-go for licensing concerns (and/or maintenance burden) ?

[mattip]

images were updated to use devtoolset-9

cool, thanks. That may solve the aarch64 problem. The accuracy issue is related to the glibc version, so will only be solved by moving past manylinux2014

[mayeut]

The glibc 2.17 version (used in redhat 7.7.1908, in manylinux2014) of complex math routines are inaccurate. This trips a blacklist of these functions in NumPy. Unfortunately, the replacement np.arcsinh also seems inaccurate on aarch64 with gcc (GCC) 9.1.1 20190605.

I thought there was a custom implementation also suffering from accuracy issues and not involving glibc. Maybe I thought wrong (or the custom implementation uses yet another function from glibc suffering an accuracy issue ?).

[mattip]

Ahh, sorry, I forgot I already tried the devtoolset-9 gcc on aarch64, and that the custom numpy implementation is only correct for x86. I think my conclusion then was the correct one: NumPy should not try to release non-x86 wheels until we can move on from glibc2.17 ( which is 8 years old)

[mayeut]

Closing this issue now that the compiler has been updated.
The accuracy issue is something else.