➜
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.
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) *  |
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) * |
Date: 2015-09-04 10:23 | |
Zachary Ware is the administrator of the buildbot. |
|||
| msg249763 - (view) | Author: R. David Murray (r.david.murray) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2015-09-08 06:23 | |
Note: the ICC buildbot does fail much more consistently on those. |
|||
| msg250165 - (view) | Author: STINNER Victor (vstinner) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2015-09-09 16:12 | |
Thanks, I've contacted Robert. |
|||
| msg250985 - (view) | Author: STINNER Victor (vstinner) * |
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) * |
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) * |
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) * |
Date: 2015-09-19 08:44 | |
This variant look overcomplicated to me. |
|||
| msg251077 - (view) | Author: Roundup Robot (python-dev)  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2015-12-23 23:04 | |
I see, thanks. I've opened #25934 to keep the issues separate. |
|||
| msg297110 - (view) | Author: STINNER Victor (vstinner) * |
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) * |
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:20 | admin | set | github: 69187 |
| 2017-06-28 05:14:36 | skrah | set | messages: + msg297152 |
| 2017-06-28 01:19:21 | vstinner | set | status: open -> closed resolution: out of date messages: + msg297110 stage: needs patch -> resolved |
| 2015-12-23 23:04:29 | skrah | set | messages: + msg256944 |
| 2015-12-23 22:53:25 | zach.ware | set | messages: + msg256942 |
| 2015-12-23 22:44:41 | skrah | set | title: 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:24 | skrah | set | messages: + msg256941 |
| 2015-11-09 17:37:54 | vstinner | set | title: 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:34 | zach.ware | set | messages: + msg254393 |
| 2015-11-08 15:34:46 | skrah | set | messages: + msg254342 |
| 2015-11-08 15:23:43 | skrah | set | messages: + msg254340 |
| 2015-11-08 01:31:20 | r.david.murray | set | messages: + msg254317 |
| 2015-11-07 16:15:03 | serhiy.storchaka | set | messages: + msg254285 |
| 2015-11-07 15:45:45 | tim.peters | set | messages: + msg254278 |
| 2015-11-07 15:36:32 | serhiy.storchaka | set | messages: + msg254276 |
| 2015-09-19 18:41:00 | mark.dickinson | set | nosy:
+ mark.dickinson |
| 2015-09-19 11:43:29 | vstinner | set | messages: + msg251078 |
| 2015-09-19 11:41:11 | python-dev | set | nosy:
+ python-dev messages: + msg251077 |
| 2015-09-19 08:44:47 | serhiy.storchaka | set | messages: + msg251067 |
| 2015-09-19 08:31:43 | vstinner | set | files:
+ pylong_digits.patch messages: + msg251066 |
| 2015-09-18 15:33:36 | serhiy.storchaka | set | messages: + msg251007 |
| 2015-09-18 13:48:01 | vstinner | set | files:
+ long_shift_ub.patch keywords: + patch messages: + msg250985 |
| 2015-09-09 16:12:10 | skrah | set | messages: + msg250320 |
| 2015-09-08 15:56:46 | r.david.murray | set | messages: + msg250230 |
| 2015-09-08 15:52:03 | skrah | set | messages: + msg250228 |
| 2015-09-08 15:34:43 | r.david.murray | set | messages: + msg250218 |
| 2015-09-08 12:03:58 | skrah | set | messages: + msg250188 |
| 2015-09-08 11:23:55 | skrah | set | messages: + msg250182 |
| 2015-09-08 07:26:42 | vstinner | set | messages: + msg250165 |
| 2015-09-08 06:23:36 | zach.ware | set | messages: + msg250162 |
| 2015-09-08 06:22:50 | zach.ware | set | messages: + msg250161 |
| 2015-09-07 21:06:35 | pitrou | set | nosy:
+ pitrou messages: + msg250130 |
| 2015-09-07 12:46:57 | skrah | set | nosy:
+ skrah messages: + msg250106 |
| 2015-09-05 22:11:34 | tim.peters | set | messages: + msg249937 |
| 2015-09-05 21:51:50 | rhettinger | set | nosy:
+ tim.peters |
| 2015-09-04 16:41:45 | zach.ware | set | messages: + msg249783 |
| 2015-09-04 16:23:57 | zach.ware | set | messages: + msg249782 |
| 2015-09-04 16:22:25 | vstinner | set | messages: + msg249781 |
| 2015-09-04 16:18:24 | serhiy.storchaka | set | messages: + msg249780 |
| 2015-09-04 15:38:40 | zach.ware | set | stage: needs patch versions: + Python 3.5 |
| 2015-09-04 15:36:47 | vstinner | set | messages: + msg249776 |
| 2015-09-04 15:34:26 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages: + msg249774 |
| 2015-09-04 14:14:18 | r.david.murray | set | nosy:
+ r.david.murray messages: + msg249763 |
| 2015-09-04 10:23:56 | vstinner | set | messages: + msg249751 |
| 2015-09-04 10:23:10 | vstinner | create | |