[Patches] [ python-Patches-730594 ] assert from longobject.c, line 1215

SourceForge.net noreply@sourceforge.net
Mon, 05 May 2003 20:12:57 -0700


Patches item #730594, was opened at 2003-05-01 14:43
Message generated for change (Comment added) made by cjohns
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Chris Johns (cjohns)
Assigned to: Tim Peters (tim_one)
Summary: assert from longobject.c, line 1215

Initial Comment:
RTEMS port running on the Coldfire (m5200) processor.
RTEMS is version 4.6.0pre3 and the lastest RTEMS tool
set. The target is m68k-rtems.

GCC 3.2.2 and GCC 3.2.3 both cause the assert in the file:

 Objects/longmodule.c:1215

The assert test is in the function 'long_from_binary_base':

  assert(k < base);

The assert and related code is valid, gcc is generating
bad code. The bad code is related to the "digit"
variable k being a short and the base being an int
(32bit on Coldfire). GCC seems to get a little confused
about which 16bit half to compare against.

The simple fix is to make "k" an int and so be the same
size as base.  The 'k' variable is an int in the loop
just above that figures out the total number of bits
needed.

This change also generated faster code for the
Coldfire. I know a selection of one CPU is not a valid
analysis, how-ever base and k being the same seemed to
help gcc.

----------------------------------------------------------------------

>Comment By: Chris Johns (cjohns)
Date: 2003-05-06 13:12

Message:
Logged In: YES 
user_id=197074

I have tested the lastest cvs. The committed change to
longobject.c, revision 1.160 did not generate an assert when
loading site.py.

This change is fine with me.

Thanks for the prompt resolution.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-06 06:40

Message:
Logged In: YES 
user_id=31435

If you could try current CVS Python, that would be great.  I 
don't mind changing the code here, but if k becomes signed 
in this loop then I don't want to continue forcing ch to be 
unsigned in this loop, so I changed more than just the one 
declaration.  I'll leave the patch open until you can find out 
whether it worms around your gcc problem.

Objects/longobject.c; new revision: 1.160

----------------------------------------------------------------------

Comment By: Chris Johns (cjohns)
Date: 2003-05-01 14:51

Message:
Logged In: YES 
user_id=197074

Be a good idea if I read the instructions and checked the
patch attached box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=730594&group_id=5470