This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Type: crash Stage: resolved
Components: Build, Windows Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, paul.moore, pitrou, python-dev, r.david.murray, serhiy.storchaka, skrah, steve.dower, tim.golden, tim.peters, vstinner, zach.ware
Priority: normal Keywords: patch

Created on 2015-09-04 10:23 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
long_shift_ub.patch vstinner, 2015-09-18 13:48 review
pylong_digits.patch vstinner, 2015-09-19 08:31 review
Messages (39)
msg249749 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-04 10:23
The crash occurred on the buildbot "x86-64 Windows Server 2012R2 ICC 3.x".

Do you we officially support the ICC compiler?

--

There are still some curious compiler warnings:

Objects\longobject.c(4498): warning #63: shift count is too large
=> "#if LONG_MAX >> 2*PyLong_SHIFT"
Objects\longobject.c(4519): warning #63: shift count is too large
=> "#if LONG_MAX >> 2*PyLong_SHIFT"

I don't understand the test: do we test if the result is zero?

On Windows, a long is only 32-bits. I guess that PyLong_SHIFT is 30 (so 2*PyLong_SHIFT=60).

Maybe we should put "#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT" before?

--

The crash itself:


http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/83/steps/test/logs/stdio

[ 14/398] test_re
Fatal Python error: Segmentation fault

Current thread 0x00000578 (most recent call first):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\re.py", line 163 in match
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_re.py", line 976 in test_sre_character_class_literals
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 600 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 648 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\runner.py", line 176 in run
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1775 in _run_suite
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1809 in run_unittest
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1280 in test_runner
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1281 in runtest_inner
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 968 in runtest
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 763 in main
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1565 in main_in_temp_cwd
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1590 in <module>
msg249751 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-04 10:23
Zachary Ware is the administrator of the buildbot.
msg249763 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-09-04 14:14
We don't officially support ICC yet, but the buildbots are a step in the direction of proposing that we do.
msg249774 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-09-04 15:34
> I don't understand the test: do we test if the result is zero?

We test that signed long is enough to contain 2 digits. May be it should be written as LONG_MAX >> PyLong_SHIFT >> PyLong_SHIFT.

> Maybe we should put "#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT" before?

No. We need to use long long only if long is not enough.
msg249776 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-04 15:36
> We test that signed long is enough to contain 2 digits. May be it should be written as LONG_MAX >> PyLong_SHIFT >> PyLong_SHIFT.

Ok, but I don't understand "if <operations on integers>". Does it mean "if <operations on integers> != 0"?

Maybe we can use SIZEOF_LONG instead of LONG_MAX?
msg249780 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-09-04 16:18
Yes, it means "if <operations on integers> != 0".

The condition is equivalent to SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT on binary computers with two-complementarn two's-complement integers. But current form looks more natural to me.
msg249781 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-04 16:22
> The condition is equivalent to SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT on binary computers with two-complementarn two's-complement integers. But current form looks more natural to me.

Oh by the way: I have no idea if the test_re crash is related to this warning :-) I don't plan to install ICC to reproduce the issue.
msg249782 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-09-04 16:23
Replacing the two instances of "LONG_MAX >> 2*PyLong_SHIFT" with "SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT" fixes the warnings, but does nothing for test_re.
msg249783 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-09-04 16:41
Another lovely facet of this segfault: it doesn't occur when built in Debug configuration.
msg249937 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2015-09-05 22:11
The longobject.c warnings are almost certainly unrelated to the test_re crash.

If shifting right twice (adding parens for clarity):

    (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT.

squashes the warnings, that would be a substantially clearer way to express the intent than the

    SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT

spelling.  Adding a comment *explaining* the intent would be even better.

For the segfault issue, best guess is that it's a compiler optimization bug.  Not common as mud, or even as common as nuisance warnings, but not all that rare either ;-)
msg250106 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-09-07 12:46
The buildbot segfaults all over the place, also in test_tokenize
and test_json:

http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/89/steps/test/logs/stdio


Running the tests under the VS debugger is probably the fastest way to find out why (I don't have the Intel compiler).
msg250130 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-09-07 21:06
I *think* shifting by an amount larger than the operand's width is undefined behaviour (at least LLVM clearly seems to think so, since it gives different results on x86 and ARM), so the compiler is probably allowed to do what it wants (even return 42).
msg250161 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-09-08 06:22
Stefan Krah commented:
> The buildbot segfaults all over the place, also in test_tokenize
> and test_json:

To be fair, other buildbots are also segfaulting (or otherwise silently failing) on those: 

3.4 on XP, test_json:
http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/1190/steps/test/logs/stdio
3.5 on 7, test_tokenize:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/250/steps/test/logs/stdio
msg250162 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-09-08 06:23
Note: the ICC buildbot does fail much more consistently on those.
msg250165 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-08 07:26
Zachary Ware added the comment:
> To be fair, other buildbots are also segfaulting (or otherwise silently failing) on those:

Sorry, the following issues are unrelated.

> 3.4 on XP, test_json:
> http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/1190/steps/test/logs/stdio

This one is old. We don't really support Windows XP. If I recall
correctly, Windows XP doesn't handle correctly stack overflow.

> 3.5 on 7, test_tokenize:
> http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/250/steps/test/logs/stdio

This is a timeout, not a crash.
msg250182 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-09-08 11:23
Yes, according to C99 the shift is undefined:

6.5.7:

"If the value of the right operand is negative or is greater than
 or equal to the width of the promoted left operand, the behavior
 is undefined."
msg250188 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-09-08 12:03
Perhaps the stack overflow hypothesis applies here, too.

You could try changing Py_DEFAULT_RECURSION_LIMIT in ceval.c
to lower values.
msg250218 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-09-08 15:34
Ah, interesting.  We know that there are stack overflow issues on the ICC windows build (they show up consistently in a debug build).
msg250228 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-09-08 15:52
Visual studio apparently has the option /F to set the stack size.
Maybe ICC has one, too.
msg250230 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-09-08 15:56
By the way Stefan, if you want a copy of the ICC compiler to test with, you can contact Robert.S.Cohn@intel.com.
msg250320 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-09-09 16:12
Thanks, I've contacted Robert.
msg250985 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-18 13:48
"""

If shifting right twice (adding parens for clarity):

    (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT.

squashes the warnings, that would be a substantially clearer way to express the intent than the

    SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT

spelling.  Adding a comment *explaining* the intent would be even better.
"""

Ok, here is a patch implementing this issue: long_shift_ub.patch.

I'm unable to test it with ICC, but we can try to push it and check on the ICC buildbots.
msg251007 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-09-18 15:33
I'm fine with both variants: (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT and SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT (the latter can be simplified to 8*SIZEOF_LONG > 2*PyLong_SHIFT). A comment on the next line explains the condition, it can be extended if needed. I'm fine with Victor's patch too.
msg251066 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-19 08:31
pylong_digits.patch: new patch add two local inlined functions _PyLong_AsDigits() and _PyLong_FromDigits() to make the code more readable. Does it look good to you?

I chose two shifts since only Tim Peters has an opinion on it, and he prefers two shifts :-)
msg251067 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-09-19 08:44
This variant look overcomplicated to me.
msg251077 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-09-19 11:41
New changeset 21076e24cd8a by Victor Stinner in branch '3.5':
Issue #24999: In longobject.c, use two shifts instead of ">> 2*PyLong_SHIFT" to
https://hg.python.org/cpython/rev/21076e24cd8a
msg251078 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-19 11:43
> This variant look overcomplicated to me.

Ok fine. I pushed  pylong_digits.patch, but I also modified a similar code a few lines below.
msg254276 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-11-07 15:36
It looks to me that all issues are related to floating points. 

======================================================================
FAIL: test_add (test.test_audioop.TestAudioop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_audioop.py", line 138, in test_add
    datas[w])
AssertionError: b'\x00\x00\x00\x00\x80V4\x12\x80\x89gE\x80v\x98\xba\x00\x00[36 chars]\xff' != b'\x00\x00\x00\x00xV4\x12\xab\x89gEUv\x98\xba\xff\xff\xff\x[30 chars]\xff'

======================================================================
FAIL: test_tostereo (test.test_audioop.TestAudioop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_audioop.py", line 438, in test_tostereo
    self.assertEqual(audioop.tostereo(data1, w, 1, 0), data2)
AssertionError: b'\x00\x00\x00\x00\x00\x00\x00\x00\x80V4\x[165 chars]\x00' != bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x[170 chars]x00')

----------------------------------------------------------------------

audioop uses double for addition of 32-bit samples and converting to stereo. On this platforms it uses only highest 25 bits (including sign) and clears lowest 7 bit.

Other tests also expose the lost of precision.

======================================================================
FAIL: test_from_hex (test.test_float.HexFloatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_float.py", line 1228, in test_from_hex
    self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_float.py", line 939, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: 0.0 not identical to 2.2250738585072014e-308

----------------------------------------------------------------------
======================================================================
ERROR: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_cmath.py", line 355, in test_specific_values
    actual = function(arg)
ValueError: math domain error

----------------------------------------------------------------------
======================================================================
FAIL: fromhex (builtins.float)
Doctest: builtins.float.fromhex
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\doctest.py", line 2189, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtins.float.fromhex
  File "builtins", line unknown line number, in fromhex

----------------------------------------------------------------------
File "builtins", line ?, in builtins.float.fromhex
Failed example:
    float.fromhex('-0x1p-1074')
Expected:
    -5e-324
Got:
    -0.0


----------------------------------------------------------------------
======================================================================
FAIL: test_bigcomp (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 213, in test_bigcomp
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.000000be3528cp-1022' != '0x0.0p+0'
- 0x0.000000be3528cp-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 9854e-319: expected 0x0.000000be3528cp-1022, got 0x0.0p+0

======================================================================
FAIL: test_boundaries (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 190, in test_boundaries
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.ffffffffffffep-1022' != '0x0.0p+0'
- 0x0.ffffffffffffep-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 22250738585072001874e-327: expected 0x0.ffffffffffffep-1022, got 0x0.0p+0

======================================================================
FAIL: test_halfway_cases (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 173, in test_halfway_cases
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.947c9545804f2p-1022' != '0x0.0p+0'
- 0x0.947c9545804f2p-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 129060066119072381453846425881820124322370272229648099639268127314770620842265843984812683156331055738253536699704952360196529596150749604030149685393298799013053728016749774464387976212748813933724362621076615872019961325756325929196058581813002404840643046271691621507677546403671954282010806041423157797170973546486726628115569923156124808066762413905989591757681932845143198849395016368313182575947314742890387780447526367065850529573409545360732184792283544657335122046047938965404774992571149865789698314241729748146943023334319000113011540774216310530508268016107235272154735009835852892749842299060764311119823575528980820809948907316616122165346751308650318747818556153406881003087722986592333293849130494158948959993772620524765670779743231832981109619140625e-1075: expected 0x0.947c9545804f2p-1022, got 0x0.0p+0

======================================================================
FAIL: test_parsing (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 242, in test_parsing
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.ebdb7a968507cp-1022' != '0x0.0p+0'
- 0x0.ebdb7a968507cp-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 20.50e-309: expected 0x0.ebdb7a968507cp-1022, got 0x0.0p+0

======================================================================
FAIL: test_particular (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 430, in test_particular
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.90bbd7412d19fp-1022' != '0x0.0p+0'
- 0x0.90bbd7412d19fp-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 12579816049008305546974391768996369464963024663104e-357: expected 0x0.90bbd7412d19fp-1022, got 0x0.0p+0

======================================================================
FAIL: test_underflow_boundary (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 204, in test_underflow_boundary
    self.check_strtod(s)
  File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_strtod.py", line 104, in check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: '0x0.0000000000001p-1022' != '0x0.0p+0'
- 0x0.0000000000001p-1022
+ 0x0.0p+0
 : Incorrectly rounded str->float conversion for 24703282292062327208828439643411068618252990130716238221279284125033775364371e-400: expected 0x0.0000000000001p-1022, got 0x0.0p+0

----------------------------------------------------------------------

May be compiler uses float instead of double? Or some FPU flag is set to handle doubles as floats?
msg254278 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2015-11-07 15:45
If it were treating doubles as floats, you'd get a lot more failures than this.

Many of these look like clear cases of treating _denormal_ doubles as 0.0, though.  I have no experience with ICC, but a quick Google search suggests ICC flushes denormals to 0.0 by default, and the compiler flag "no-ftz" (no flush-to-zero) is needed to stop that; e.g., see

https://software.intel.com/sites/default/files/article/326703/fp-control-2012-08.pdf
msg254285 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-11-07 16:15
test_audioop fails because (int)((double)0x12345678+0.0) is truncated to 0x12345680 and (int)((double)-0x456789ab+0.0) to -0x45678980.
msg254317 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-11-08 01:31
FYI Intel provided us with a workaround that disables a compiler optimization for re and allows the test to not crash.  Zach, can you test no-ftz? Maybe we need to apply that to the entire python compile.  Also, can you make sure the appropriate person from Intel is nosy on this issue, assuming they have already registered?

Tim: any idea why would this only show up on Windows?  Also, if you want a copy of ICC to play with, we can arrange that.
 
I wonder if this issue has any effect on Intel's numpy support.
msg254340 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-11-08 15:23
> It looks to me that all issues are related to floating points.

You need to compile with "-fp-model strict" or the Windows
equivalent (I think "-fp-model precise").
msg254342 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-11-08 15:34
If anyone worries that "-fp-model strict" will slow
things down:  In the Python context these settings have
no measurable impact:  A while ago I tested setting/restoring
the control word *for every operation*, and even that did
not have any impact.
msg254393 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-11-09 16:16
Stefan Krah wrote:
> If anyone worries that "-fp-model strict" will slow
> things down:  In the Python context these settings have
> no measurable impact:  A while ago I tested setting/restoring
> the control word *for every operation*, and even that did
> not have any impact.

If that's the case, would anyone (in particular, Steve, Tim or Tim) mind if we just made the default (for MSVC as well as ICC) /fp:strict?  It would be much easier to just change the global default than to try to either make it settable or to change it just when ICC is used.

As far as the segfault that this issue is actually about, compiling _sre.c with /Os seems to clear it up.  I believe Intel is looking into it deeper to determine whether it's an ICC bug or if there's something we should change in _sre.c.
msg256941 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-12-23 22:42
The current issue description should have been fixed by #25827.
Is the segfault in test_re still happening?
msg256942 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-12-23 22:53
Unfortunately, #25827 has no effect on Windows, which is where this issue occurs.  There are still several segfaults on Windows, including test_re.
msg256944 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-12-23 23:04
I see, thanks.  I've opened #25934 to keep the issues separate.
msg297110 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-06-28 01:19
The two ICC buildbots are now offline. ICC was never really officially supported, so I just close this old issue (no activity since the end of 2015).
msg297152 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-06-28 05:14
icc on Linux has always worked exactly as gcc, except that -fp-model=strict needs to be specified.

I can't test on Windows -- I don't seem to get MSVC licences any more.
History
Date User Action Args
2022-04-11 14:58:20adminsetgithub: 69187
2017-06-28 05:14:36skrahsetmessages: + msg297152
2017-06-28 01:19:21vstinnersetstatus: open -> closed
resolution: out of date
messages: + msg297110

stage: needs patch -> resolved
2015-12-23 23:04:29skrahsetmessages: + msg256944
2015-12-23 22:53:25zach.waresetmessages: + msg256942
2015-12-23 22:44:41skrahsettitle: ICC compiler: ICC treats denormal floating point numbers as 0.0 -> Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
2015-12-23 22:42:24skrahsetmessages: + msg256941
2015-11-09 17:37:54vstinnersettitle: Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC -> ICC compiler: ICC treats denormal floating point numbers as 0.0
2015-11-09 16:16:34zach.waresetmessages: + msg254393
2015-11-08 15:34:46skrahsetmessages: + msg254342
2015-11-08 15:23:43skrahsetmessages: + msg254340
2015-11-08 01:31:20r.david.murraysetmessages: + msg254317
2015-11-07 16:15:03serhiy.storchakasetmessages: + msg254285
2015-11-07 15:45:45tim.peterssetmessages: + msg254278
2015-11-07 15:36:32serhiy.storchakasetmessages: + msg254276
2015-09-19 18:41:00mark.dickinsonsetnosy: + mark.dickinson
2015-09-19 11:43:29vstinnersetmessages: + msg251078
2015-09-19 11:41:11python-devsetnosy: + python-dev
messages: + msg251077
2015-09-19 08:44:47serhiy.storchakasetmessages: + msg251067
2015-09-19 08:31:43vstinnersetfiles: + pylong_digits.patch

messages: + msg251066
2015-09-18 15:33:36serhiy.storchakasetmessages: + msg251007
2015-09-18 13:48:01vstinnersetfiles: + long_shift_ub.patch
keywords: + patch
messages: + msg250985
2015-09-09 16:12:10skrahsetmessages: + msg250320
2015-09-08 15:56:46r.david.murraysetmessages: + msg250230
2015-09-08 15:52:03skrahsetmessages: + msg250228
2015-09-08 15:34:43r.david.murraysetmessages: + msg250218
2015-09-08 12:03:58skrahsetmessages: + msg250188
2015-09-08 11:23:55skrahsetmessages: + msg250182
2015-09-08 07:26:42vstinnersetmessages: + msg250165
2015-09-08 06:23:36zach.waresetmessages: + msg250162
2015-09-08 06:22:50zach.waresetmessages: + msg250161
2015-09-07 21:06:35pitrousetnosy: + pitrou
messages: + msg250130
2015-09-07 12:46:57skrahsetnosy: + skrah
messages: + msg250106
2015-09-05 22:11:34tim.peterssetmessages: + msg249937
2015-09-05 21:51:50rhettingersetnosy: + tim.peters
2015-09-04 16:41:45zach.waresetmessages: + msg249783
2015-09-04 16:23:57zach.waresetmessages: + msg249782
2015-09-04 16:22:25vstinnersetmessages: + msg249781
2015-09-04 16:18:24serhiy.storchakasetmessages: + msg249780
2015-09-04 15:38:40zach.waresetstage: needs patch
versions: + Python 3.5
2015-09-04 15:36:47vstinnersetmessages: + msg249776
2015-09-04 15:34:26serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg249774
2015-09-04 14:14:18r.david.murraysetnosy: + r.david.murray
messages: + msg249763
2015-09-04 10:23:56vstinnersetmessages: + msg249751
2015-09-04 10:23:10vstinnercreate