[issue40223] Add -fwrapv for new icc versions

Stefan Krah added the comment: It looks like a compiler bug (line numbers are after macro expansion): #0 0x006ea678 in _PyEval_EvalFrameDefault (f=0x886d20 <_PyRuntime+352>, throwflag=-8) at Python/ceval.c:35554 #1 0x0057167b in _PyEval_EvalCodeWithName (_co=0x886d20 <_PyR

[issue40223] Add -fwrapv for new icc versions

Benjamin Peterson added the comment: I agree that your fix it correct, though because even if the specific issue you saw is a compiler bug, we need to tell our compilers than Python assumes signed wraparound. -- ___ Python tracker

[issue40223] Add -fwrapv for new icc versions

Stefan Krah added the comment: Yeah, I already felt a bit guilty about adding you -- it could be a compiler bug or an actual overflow. My bet is also that the reordering exposes an existing overflow. The reordering itself certainly looks correct to me. When I have time, I'll try to look in

[issue40223] Add -fwrapv for new icc versions

Benjamin Peterson added the comment: I don't readily have access to ICC, so I can't personally debug this. That commit was supposed to be a functional noop, though it may have exposed different optimization opportunities to the compiler. I would like to see Python not assumed signed overflow

[issue40223] Add -fwrapv for new icc versions

Stefan Krah added the comment: cc Benjamin, in case he has any ideas: icc does not like the label reordering in ceval.c, but that can be anything from an icc issue to an actual overflow in ceval.c. -- nosy: +benjamin.peterson ___ Python tracker

[issue40223] Add -fwrapv for new icc versions

Stefan Krah added the comment: icc does not like the label reordering from: ddd1949fea59f256e51191540a4446f75ed608fa This is one step further, but not much. Possibilities are still: 1) The reordering exposes an overflow. 2) The new ordering is not supported by icc, it introduces U

[issue40223] Add -fwrapv for new icc versions

Laël Cellier added the comment: since ‑fwrapv is the default with ɢᴄᴄ as ‑O2 is used in Cpython build scripts. -- ___ Python tracker ___ ___

[issue40223] Add -fwrapv for new icc versions

Laël Cellier added the comment: No I’m meaning disabling all optimization when using gcc and using ‑ftrapv. This should cause the same problem : a crashing binary… -- ___ Python tracker _

[issue40223] Add -fwrapv for new icc versions

Stefan Krah added the comment: I'm aware of what -fwrapv does, it is a long standing issue in Python. I didn't try to find the exact location of overflow, since we also use -fwrapv for gcc. It is also possible that giving -fwrapv to icc disables another optimization that is the actual culpr

[issue40223] Add -fwrapv for new icc versions

Laël Cellier added the comment: If -fwrapv isn’t enabled (whereas with gcc this is the default with ‑O2), then it means -ftrapv is enabled. And from the manual page : This option generates traps for signed overflow on addition, subtraction, multiplication operations. Did you checked if the b

[issue40223] Add -fwrapv for new icc versions

Furkan Onder added the comment: Pr has been sent. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue40223] Add -fwrapv for new icc versions

Change by Furkan Onder : -- keywords: +patch nosy: +furkanonder nosy_count: 1.0 -> 2.0 pull_requests: +18905 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/19561 ___ Python tracker

[issue40223] Add -fwrapv for new icc versions

New submission from Stefan Krah : Newer icc version require -fwrapv: https://software.intel.com/en-us/forums/intel-c-compiler/topic/849064 -- components: Build messages: 365976 nosy: skrah priority: normal severity: normal stage: needs patch status: open title: Add -fwrapv for new icc