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.

Logged In: YES 
user_id=197074

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

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

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.

Logged In: YES 
user_id=31435

Thank you for the followup!  Marking as Closed.