[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

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

[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

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

[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

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

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 I

[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

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 de

[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) -- Traceba

[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[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 ___ Pyth

[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 ___ ___ Python-bugs-list mailing li

[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: 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 ne

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

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

[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 mailing list Unsubscribe:

[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: 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: 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: 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

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 tra

[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: > http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/

[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 ___ ___ Python

[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: http://buildbot.python.org/all/builders/x

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

Antoine Pitrou added the comment: 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). --

[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

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 int

[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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[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

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

[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 this

[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

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

[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: > 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_M

[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

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

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