[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: 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. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: 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). -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Changes by Stefan Krah : -- 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 ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: Unfortunately, #25827 has no effect on Windows, which is where this issue occurs. There are still several segfaults on Windows, including test_re. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: I see, thanks. I've opened #25934 to keep the issues separate. -- ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: > 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"). -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: 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. --

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: It looks to me that all issues are related to floating points. == FAIL: test_add (test.test_audioop.TestAudioop) --

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Tim Peters added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: test_audioop fails because (int)((double)0x12345678+0.0) is truncated to 0x12345680 and (int)((double)-0x456789ab+0.0) to -0x45678980. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

R. David Murray added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: 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 :-)

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: This variant look overcomplicated to me. -- ___ Python tracker ___ ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: > This variant look overcomplicated to me. Ok fine. I pushed pylong_digits.patch, but I also modified a similar code a few lines below. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Roundup Robot added the comment: 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 -- nosy: +python-dev ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: Thanks, I've contacted Robert. -- ___ Python tracker ___ ___ Python-bugs-list

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: 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: >

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: Note: the ICC buildbot does fail much more consistently on those. -- ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: 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:

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: 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." -- ___ Python

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: Perhaps the stack overflow hypothesis applies here, too. You could try changing Py_DEFAULT_RECURSION_LIMIT in ceval.c to lower values. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

R. David Murray added the comment: Ah, interesting. We know that there are stack overflow issues on the ICC windows build (they show up consistently in a debug build). -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: Visual studio apparently has the option /F to set the stack size. Maybe ICC has one, too. -- ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

R. David Murray added the comment: By the way Stefan, if you want a copy of the ICC compiler to test with, you can contact robert.s.c...@intel.com. -- ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Stefan Krah added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Changes by Raymond Hettinger : -- nosy: +tim.peters ___ Python tracker ___ ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Tim Peters added the comment: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

New submission from STINNER Victor: 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: Zachary Ware is the administrator of the buildbot. -- ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

R. David Murray added the comment: We don't officially support ICC yet, but the buildbots are a step in the direction of proposing that we do. -- nosy: +r.david.murray ___ Python tracker

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: > 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) &&

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Changes by Zachary Ware : -- stage: -> needs patch versions: +Python 3.5 ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: Another lovely facet of this segfault: it doesn't occur when built in Debug configuration. -- ___ Python tracker ___

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: > 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

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

STINNER Victor added the comment: > 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 ". Does it mean "if != 0"? Maybe we can use SIZEOF_LONG instead of LONG_MAX? --

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Serhiy Storchaka added the comment: Yes, it means "if != 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. --

[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC

Zachary Ware added the comment: 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. -- ___ Python tracker