Skip to content

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

Open

Description

@bnavigator

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]'

Activity

  1. mattip commented on Feb 10, 2021

    @mattip
    Member

    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?

  2. charris commented on Feb 10, 2021

    @charris
    Member

    i586 is really old, do things work for i686?

  3. charris commented on Feb 10, 2021

    @charris
    Member

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

  4. mattip commented on Feb 10, 2021

    @mattip
    Member

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

  5. bnavigator commented on Feb 10, 2021

    @bnavigator
    ContributorAuthor

    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

  6. bnavigator commented on Feb 10, 2021

    @bnavigator
    ContributorAuthor

    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.

  7. mattip commented on Feb 10, 2021

    @mattip
    Member

    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
    
  8. added this to the 1.20.2 release milestone on Feb 10, 2021
  9. bnavigator commented on Feb 10, 2021

    @bnavigator
    ContributorAuthor
    [  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.

  10. bnavigator commented on Feb 10, 2021

    @bnavigator
    ContributorAuthor

    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

  11. mattip commented on Feb 10, 2021

    @mattip
    Member

    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.

  12. removed this from the 1.20.2 release milestone on Mar 27, 2021
  13. charris commented on Mar 27, 2021

    @charris
    Member

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions