Skip to content

BUG: exp on macOS fails tests #13586

Closed
Closed

Description

@mattip

@tylerjereddy reports the following test failure output from the latest master branch commit (8a421d9) when running full test suite on a Mac laptop:

@r-devulap, @juliantaylor - any thoughts?

Details
________________________ TestSpecialFloats.test_exp_values _________________________
[gw1] darwin -- Python 3.6.5 /Users/treddy/miniconda3/envs/numpy_dev_py36/bin/python

self = <numpy.core.tests.test_umath.TestSpecialFloats object at 0x11bccdac8>

    def test_exp_values(self):
        x = [np.nan,  np.nan, np.inf, 0.]
        y = [np.nan, -np.nan, np.inf, -np.inf]
        for dt in ['f', 'd', 'g']:
            xf = np.array(x, dtype=dt)
            yf = np.array(y, dtype=dt)
>           assert_equal(np.exp(yf), xf)
E           RuntimeWarning: invalid value encountered in exp

dt         = 'f'
self       = <numpy.core.tests.test_umath.TestSpecialFloats object at 0x11bccdac8>
x          = [nan, nan, inf, 0.0]
xf         = array([nan, nan, inf,  0.], dtype=float32)
y          = [nan, nan, inf, -inf]
yf         = array([ nan,  nan,  inf, -inf], dtype=float32)

numpy/core/tests/test_umath.py:659: RuntimeWarning
1 failed, 8641 passed, 63 skipped, 15 xfailed, 3 xpassed in 120.79 seconds

Activity

  1. added this to the milestone on May 19, 2019
  2. r-devulap commented on May 19, 2019

    @r-devulap
    Member

    I was able to reproduce this on my SKX, but only when built with clang7.0 (it passes when run with gcc7 and clang6.0). I will debug later today to see where it's coming from ..

  3. r-devulap commented on May 19, 2019

    @r-devulap
    Member

    This is the instruction that is raising invalid exception: xmin_mask = _mm256_cmp_ps(x, _mm256_set1_ps(xmin), _CMP_LE_OQ); when x is a nan. Not sure whats special with clang7.0

  4. mattip commented on May 19, 2019

    @mattip
    MemberAuthor

    maybe a bug in clang?

  5. r-devulap commented on May 19, 2019

    @r-devulap
    Member

    probably, _CMP_LE_OQ is supposed to non-signaling and as far as I understand that shouldn't set a floating point exception.

  6. r-devulap commented on May 19, 2019

    @r-devulap
    Member

    Yeah I think this is a clang7 behavior which seems incorrect. I wrote a small test case to confirm this:

    printf("mxcsr before = %x\n", _mm_getcsr());                                
    __m256 xmin_mask = _mm256_cmp_ps(_mm256_set1_ps(nan), _mm256_set1_ps(1), _CMP_LE_OQ);
    printf("mxcsr after = %x\n", _mm_getcsr()); 
    

    With gcc and clang6.0:

    mxcsr before = 1f80
    mxcsr after = 1f80
    

    with clang7.0, it sets the invalid bit which I think is incorrect.

    mxcsr before = 1f80
    mxcsr after = 1f81
    
  7. r-devulap commented on May 19, 2019

    @r-devulap
    Member

    This test test_exp_values only cares about the value of the output, I think it might be okay to disable FPE exceptions just for this test with with np.errstate(all='ignore'):

  8. mattip commented on May 19, 2019

    @mattip
    MemberAuthor

    @charris: We have a mechanism for whitelist/blacklisting compiler bugs, how does it work?

  9. charris commented on May 19, 2019

    @charris
    Member

    @mattip We have a mechanism for library math functions, but this looks like a constant macro which is probably used to direct a compilation path. If we can detect it during configuration and have a fall back function we can fix it, but I'm not sure what the fallback function would be.

  10. charris commented on May 19, 2019

    @charris
    Member

    _CMP_LE_OQ I wonder what the actual value of this macro is? We could possibly detect/fix that, but it might be architecture dependent.

  11. r-devulap commented on May 20, 2019

    @r-devulap
    Member

    Its 18 and I think it should be the same across x86 architecture. See https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=3004,3045,3005,2822,737&text=cmp_ps

  12. r-devulap commented on May 28, 2019

    @r-devulap
    Member

    perhaps this and issue #13400 can be closed now?

  13. tylerjereddy commented on May 29, 2019

    @tylerjereddy
    Contributor

    I can definitely close this because I confirmed the fix this morning.

    Perhaps Julian should close the other, though it looks connected at a quick glance.

  14. tylerjereddy commented on May 29, 2019

    @tylerjereddy
    Contributor

    Thanks @r-devulap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions