Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: exp on macOS fails tests #13586

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.

Sign up for GitHub

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

Jump to bottom
Closed
mattip opened this issue May 19, 2019 · 13 comments
Closed

BUG: exp on macOS fails tests #13586

mattip opened this issue May 19, 2019 · 13 comments
Labels
00 - Bug component: numpy.ufunc

Comments

@mattip
Copy link
Member

mattip commented May 19, 2019

@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?

________________________ 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
@mattip mattip added this to the 1.17.0 release milestone May 19, 2019
@r-devulap
Copy link
Member

r-devulap commented May 19, 2019 •
edited
Loading

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 ..

@r-devulap
Copy link
Member

r-devulap commented May 19, 2019 •
edited
Loading

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

@mattip
Copy link
Member Author

mattip commented May 19, 2019

maybe a bug in clang?

@r-devulap
Copy link
Member

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

@mattip mattip mentioned this issue May 19, 2019
Merged
@r-devulap
Copy link
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

@r-devulap
Copy link
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'):

@mattip
Copy link
Member Author

mattip commented May 19, 2019

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

@charris
Copy link
Member

charris commented May 19, 2019

@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.

@charris
Copy link
Member

charris commented May 19, 2019

_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.

@r-devulap
Copy link
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

@r-devulap r-devulap mentioned this issue May 23, 2019
Closed
@mattip mattip mentioned this issue May 25, 2019
Open
@r-devulap r-devulap mentioned this issue May 25, 2019
Merged
@r-devulap
Copy link
Member

perhaps this and issue #13400 can be closed now?

@tylerjereddy
Copy link
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.

@tylerjereddy
Copy link
Contributor

Thanks @r-devulap

@r-devulap r-devulap mentioned this issue Dec 21, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy.ufunc
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@charris @mattip @tylerjereddy @r-devulap