[pypy-issue] [issue1072] Fatal RPython error: OverflowError

Armin Rigo tracker at bugs.pypy.org
Mon Feb 27 12:00:58 CET 2012


Armin Rigo <armin.rigo at gmail.com> added the comment:

It looks like a bug in the optimizer.  The code generated is like this:

In some loop:

+508: i45 = getfield_gc_pure(p10, descr=<FieldS
pypy.objspace.std.intobject.W_IntObject.inst_intval 8>)
...
+587: i51 = int_mul_ovf(2, i45)
guard_no_overflow(, descr=<Guard256>) [p1, p0, p10, i51, p2, p5, p12, p49, None,
p40]

This fails often and generates a bridge (notice that it passes p10->p2):

# bridge out of Guard 256 with 37 ops
[p0, p1, p2, i3, p4, p5, p6, p7, p8]
+37: i9 = getfield_gc_pure(p2, descr=<FieldS
pypy.objspace.std.intobject.W_IntObject.inst_intval 8>)
+41: p11 = call(ConstClass(fromint), i9, descr=<Callr 8 i EF=3>)
...
+387: i35 = int_mul_ovf(2, i9)
guard_no_overflow(, descr=<Guard432>) [p0, p1, p4, p5, p2, p6, p28, None, None,
None, None, None, p7, p8]
+403: p37 = call(ConstClass(fromint), i35, descr=<Callr 8 i EF=3>)
+422: jump(p1, p0, p4, p5, p2, p28, p6, p8, p7, p19, p11, p37, i35,
descr=TargetToken(140737312245264))

This last int_mul_ovf/guard_no_overflow is strange, and will obviously always
fail.  When it does, it fails at an unexpected place, not at all at the place
that is ready to catch the RPython-level OverflowError.

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1072>
________________________________________


More information about the pypy-issue mailing list