[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 
<_PyRuntime+352>, globals=0xfff8, locals=0x, 
args=0x1, argcount=9370836, kwnames=0x0, kwargs=0x90bd90, kwcount=0, kwstep=1, 
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x8f05a0, 
qualname=0x8f05a0) at Python/ceval.c:33634
#2  0x0043a693 in _PyFunction_FastCallKeywords (func=0x886d20 
<_PyRuntime+352>, stack=0xfff8, nargs=-1, kwnames=0x1) at 
Objects/call.c:433
#3  0x006e65f5 in call_function (pp_stack=0x886d20 <_PyRuntime+352>, 
oparg=-8, kwnames=0x) at Python/ceval.c:37762
#4  0x006eb7a8 in _PyEval_EvalFrameDefault (f=0x886d20 
<_PyRuntime+352>, throwflag=-8) at Python/ceval.c:36385
#5  0x0057167b in _PyEval_EvalCodeWithName (_co=0x886d20 
<_PyRuntime+352>, globals=0xfff8, locals=0x, 
args=0x1, argcount=9370836, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, 
defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at 
Python/ceval.c:33634
#6  0x00571e41 in PyEval_EvalCodeEx (_co=0x886d20 <_PyRuntime+352>, 
globals=0xfff8, locals=0x, args=0x1, 
argcount=9370836, kws=0x0, kwcount=2, defs=0x0, defcount=0, kwdefs=0x0, 
closure=0x0)
at Python/ceval.c:37166
#7  0x006bdb95 in builtin___build_class__ (self=0x886d20 
<_PyRuntime+352>, args=0xfff8, nargs=-1, kwnames=0x1) at 
Python/bltinmodule.c:221
#8  0x0043a41e in _PyMethodDef_RawFastCallKeywords (method=0x886d20 
<_PyRuntime+352>, self=0xfff8, args=0x, nargs=1, 
kwnames=0x8efcd4) at Objects/call.c:656
#9  0x0043ada6 in _PyCFunction_FastCallKeywords (func=0x886d20 
<_PyRuntime+352>, args=0xfff8, nargs=-1, kwnames=0x1) at 
Objects/call.c:730
#10 0x006e6a64 in call_function (pp_stack=0x886d20 <_PyRuntime+352>, 
oparg=-8, kwnames=0x) at Python/ceval.c:37714
#11 0x006eb7a8 in _PyEval_EvalFrameDefault (f=0x886d20 
<_PyRuntime+352>, throwflag=-8) at Python/ceval.c:36385
#12 0x0057167b in _PyEval_EvalCodeWithName (_co=0x886d20 
<_PyRuntime+352>, globals=0xfff8, locals=0x, 
args=0x1, argcount=9370836, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, 
defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at 
Python/ceval.c:33634
#13 0x00570c52 in PyEval_EvalCodeEx (_co=, 
globals=, locals=, args=, 
argcount=, kws=, kwcount=, 
defs=, defcount=, kwdefs=, 
closure=) at Python/ceval.c:37166
#14 PyEval_EvalCode (co=0x886d20 <_PyRuntime+352>, globals=0xfff8, 
locals=0x) at Python/ceval.c:33611
#15 0x005b20ba in exec_code_in_module (name=, 
module_dict=, code_object=) at Python/import.c:952
#16 PyImport_ImportFrozenModuleObject (name=) at 
Python/import.c:1357
#17 PyImport_ImportFrozenModule (name=0x886d20 <_PyRuntime+352> "\020\023\216") 
at Python/import.c:1376
#18 0x005ca1f7 in _Py_InitializeCore_impl (interp_p=0xfff8, 
core_config=0x) at Python/pylifecycle.c:197
#19 0x005c9be5 in _Py_InitializeCore (interp_p=0xfff8, 
src_config=0x) at Python/pylifecycle.c:745
#20 0x00429859 in pymain_init (pymain=0x886d20 <_PyRuntime+352>, 
interp_p=0xfff8) at Modules/main.c:1733
#21 0x00428ddf in pymain_main (pymain=) at 
Modules/main.c:1753
#22 _Py_UnixMain (argc=8940832, argv=0xfff8) at Modules/main.c:1792
#23 0x77c90f43 in __libc_start_main () from /lib64/libc.so.6
#24 0x0042652e in _start ()


In frame 13 argcount is still 0:

#13 0x00570c52 in PyEval_EvalCodeEx (_co=, 
globals=, locals=, args=, 
argcount=, kws=, kwcount=, 
defs=, defcount=, kwdefs=, 
closure=) at Python/ceval.c:37166
37166   return _PyEval_EvalCodeWithName(_co, globals, locals,
(gdb) l
37161 PyObject *const *kws, int kwcount,
37162 PyObject *const *defs, int defcount,
37163 PyObject *kwdefs, PyObject *closure)
37164   {
37165   if (argcount != 0) abort();
37166   return _PyEval_EvalCodeWithName(_co, globals, locals,
37167   args, argcount,
37168   kws, kws != ((void*)0) ? kws + 1 : 
((void*)0),
37169   kwcount, 2,
37170   defs, defcount,


In frame 12 it looks uninitialized:

(gdb) f 12
#12 0x0057167b in _PyEval_EvalCodeWithName (_co=0x886d20 
<_PyRuntime+352>, globals=0xfff8, locals=0x, 
args=0x1, argcount=9370836, kwnames=0x0, kwargs=0x0, kwcount=0, k

[issue40223] Add -fwrapv for new icc versions

[Benjamin Peterson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 into it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Benjamin Peterson]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 UB
  that is masked by -fwrapv (again, does -fwrapv only disable
  a single optimization? My guess is that it disables several).


This was found by automated bisecting, I still have no time to really
investigate what is going on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Laël Cellier]

Laël Cellier  added the comment:

since ‑fwrapv is the default with ɢᴄᴄ as ‑O2 is used in Cpython build scripts.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Laël Cellier]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 culprit.

But I don't have time to figure out any of that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Laël Cellier]

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 binary compiles fines with all ‑O2/‑O3 options replaced 
with ‑O0 in configure/Makefiles along gcc ?

--
nosy: +Laël Cellier

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Furkan Onder]

Furkan Onder  added the comment:

Pr has been sent.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Furkan Onder]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40223] Add -fwrapv for new icc versions

[Stefan Krah]

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 versions
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com