8000 test_float_remainder_overflow fails on intel 32-bit because divmod(_, tiny) does not raise invalid value · Issue #18388 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

test_float_remainder_overflow fails on intel 32-bit because divmod(_, tiny) does not raise invalid value #18388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bnavigator opened this issue Feb 10, 2021 · 11 comments

Comments

@bnavigator
Copy link
Contributor

While building and testing NumPy 1.20.0 for openSUSE Tumbleweed on i586 architecture:

[ 1044s] _________________ TestRemainder.test_float_remainder_overflow __________________
[ 1044s] [gw7] linux -- Python 3.8.7 /usr/bin/python3.8
[ 1044s] 
[ 1044s] self = <numpy.core.tests.test_umath.TestRemainder object at 0xf075f448>
[ 1044s] 
[ 1044s]     def test_float_remainder_overflow(self):
[ 1044s]         a = np.finfo(np.float64).tiny
[ 1044s]         with np.errstate(over='ignore', invalid='ignore'):
[ 1044s]             div, mod = np.divmod(4, a)
[ 1044s]             np.isinf(div)
[ 1044s]             assert_(mod == 0)
[ 1044s]         with np.errstate(over='raise', invalid='ignore'):
[ 1044s]             assert_raises(FloatingPointError, np.divmod, 4, a)
[ 1044s]         with np.errstate(invalid='raise', over='ignore'):
[ 1044s] >           assert_raises(FloatingPointError, np.divmod, 4, a)
[ 1044s] 
[ 1044s] ../../../BUILDROOT/python-numpy-1.20.0-90.1.i386/usr/lib/python3.8/site-packages/numpy/core/tests/test_umath.py:449: 
[ 1044s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
[ 1044s] /usr/lib/python3.8/unittest/case.py:816: in assertRaises
[ 1044s]     return context.handle('assertRaises', args, kwargs)
[ 1044s] /usr/lib/python3.8/unittest/case.py:202: in handle
[ 1044s]     callable_obj(*args, **kwargs)
[ 1044s] /usr/lib/python3.8/unittest/case.py:224: in __exit__
[ 1044s]     self._raiseFailure("{} not raised by {}".format(exc_name,
[ 1044s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
[ 1044s] 
[ 1044s] self = <unittest.case._AssertRaisesContext object at 0xf075f778>
[ 1044s] standardMsg = 'FloatingPointError not raised by divmod'
[ 1044s] 
[ 1044s]     def _raiseFailure(self, standardMsg):
[ 1044s]         msg = self.test_case._formatMessage(self.msg, standardMsg)
[ 1044s] >       raise self.test_case.failureException(msg)
[ 1044s] E       AssertionError: FloatingPointError not raised by divmod
[ 1044s] 
[ 1044s] /usr/lib/python3.8/unittest/case.py:164: AssertionError
(Pdb) p a
2.2250738585072014e-308
(Pdb) np.divmod(4,a)
*** RuntimeWarning: overflow encountered in divmod
(Pdb) with np.errstate(over='raise', invalid='ignore'): np.divmod(4,a)
*** FloatingPointError: overflow encountered in divmod
(Pdb) with np.errstate(over='ignore', invalid='raise'): np.divmod(4,a)
(inf, 0.0)
(Pdb) p np.__version__
'1.20.0'
(Pdb) sys.version
'3.8.7 (default, Dec 22 2020, 08:33:13) [GCC]'
@mattip
Copy link
Member
mattip commented Feb 10, 2021

I assume 1.19 passes, and that this is inside a qemu? Could you show the first few lines of the test log where it reports what CPU features are in play?

@charris
Copy link
Member
charris commented Feb 10, 2021
8000

i586 is really old, do things work for i686?

@charris
Copy link
Member
charris commented Feb 10, 2021

I think we reguire SSE2, which came in with i786 (2000).

@mattip
Copy link
Member
mattip commented Feb 10, 2021

we should make that a hard requirement and not install on these machines

@bnavigator
Copy link
Contributor Author

Yes this is a qemu on the opensuse build sevice. AFAICT SSE2 is enabled. Yes 1.19.5 passes.

Here is the full buildlog:
numpy-1.20-i586_log.txt

@bnavigator
Copy link
Contributor Author

Don't be mislead by the 'i586' name. Yes, that is the name for the openSUSE build service. RPM internally even calls it i386. Yet this is the same as any other 32-bit Linux.

@mattip
Copy link
Member
mattip commented Feb 10, 2021

The "NumPy CPU features" line I am looking for in the log does not appear. In our CI runs it is this:

NumPy version 1.21.0.dev0+725.g0316d19de
NumPy relaxed strides checking option: True
NumPy CPU features: SSE SSE2 SSE3 SSSE3* SSE41* POPCNT* SSE42* AVX* F16C* FMA3* AVX2* AVX512F? AVX512CD? AVX512_KNL? AVX512_KNM? AVX512_SKX? AVX512_CNL?
============================= test session starts ==============================
platform linux -- Python 3.7.9, pytest-6.2.2, py-1.10.0, pluggy-0.13.1
rootdir: /home/runner/work/numpy/numpy, configfile: pytest.ini

@seberg seberg added this to the 1.20.2 release milestone Feb 10, 2021
@bnavigator
Copy link
Contributor Author
[  695s] CPU dispatch  : 
[  695s]   Requested   : 'max -xop -fma4'
[  695s]   Enabled     : SSE3 SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_KNL AVX512_KNM AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL
[  695s]   Generated   : non

I assume you have a pytest plugin generating the pytest header?. We do not build inline into the source tree. But let me check how to optimize the test rig setup.

@bnavigator
Copy link
Contributor Author
bnavigator commented Feb 10, 2021

I found the report line. It's not in conftest.py but you use a custom _pytesttester

[  206s] + python3.8 -c 'from numpy import _pytesttester as ptt; ptt._show_numpy_info()'
[  206s] NumPy version 1.20.0
[  206s] NumPy relaxed strides checking option: True
[  206s] NumPy CPU features: SSE SSE2 SSE3* SSSE3* SSE41* POPCNT* SSE42* AVX* F16C* FMA3* AVX2* AVX512F? AVX512CD? AVX512_KNL? AVX512_KNM? AVX512_SKX? AVX512_CLX? AVX512_CNL? AVX512_ICL?

numpy-1.20-i586_numpy_info_log.txt

@mattip
Copy link
Member
mattip commented Feb 10, 2021

Thanks. Our 32-bit run uses the same features

NumPy relaxed strides checking option: True
NumPy CPU features: SSE SSE2 SSE3* SSSE3* SSE41* POPCNT* SSE42* AVX* F16C* FMA3* AVX2* AVX512F? AVX512CD? AVX512_SKX? AVX512_CLX? AVX512_CNL?

This is building and testing inside the manylinux2010 32 bit docker, and not qemu.

@charris charris removed this from the 1.20.2 release milestone Mar 27, 2021
@charris
Copy link
Member
charris commented Mar 27, 2021

I cleared the milestone as this is likely an environment issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
0