[Python-bugs-list] [ python-Bugs-435026 ] SGI cores on 1.0 / 0
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 17 Jul 2001 12:11:01 -0700
Bugs item #435026, was opened at 2001-06-20 23:18
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435026&group_id=5470
Category: Python Interpreter Core
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Drew Whitehouse (drw900)
Assigned to: Tim Peters (tim_one)
Summary: SGI cores on 1.0 / 0
Initial Comment:
python21 cores evaluating 1.0 / 0 on SGI.
MIPSpro Compilers: Version 7.3.1.1m
SGI_ABI = -n32
----------------------------------------------------------------------
Comment By: Robert Minsk (rminsk)
Date: 2001-07-17 12:11
Message:
Logged In: YES
user_id=132786
Can you please look at the patch I submited on this bug. I
do not think SGI users should suffer because of a compiler
bug when a simple workaround exists.
----------------------------------------------------------------------
Comment By: Robert Minsk (rminsk)
Date: 2001-06-25 13:23
Message:
Logged In: YES
user_id=132786
I think we should we change the status of this bug. There
is something we can do to keep the same speed on other
platforms and work on the SGI. We can make condition code
on the sgi by using
#ifdef __sgi
Please see bug/patch 436193
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-06-22 20:00
Message:
Logged In: YES
user_id=31435
Nice work, Robert! Now we have a problem: when an
optimizer is doing something wrong, then typically (a)
there are any number of changes you could make that mask
the problem under a specific release of the compiler, but
(b) they're accidents, so it will just break again under
some other release of the compiler. The PyFloat_AS_DOUBLE
() is deliberately under the protection of an "if" test
that ensures its legality, so the compiler is insane (not
following the rules) in generating code that ignores this:
how do you out-think an insane algorithm? You can fool it
at random, but since it's not playing by the rules there's
nothing *reliable* you can do.
For that reason, I'm changing this to "3rd Party" and
closing with "Won't Fix" -- it's not our doing, and there's
nothing principled we can do about it short of slowing the
code on all platforms (by, e.g., using an external function
form of PyFloat_AS_DOUBLE, thus inhibiting the bad code
generation).
By the way, ask SGI to add Python to their standard
compiler regression suite: *something* is always broken on
SGI boxes, and disabling optimization always fixes it.
----------------------------------------------------------------------
Comment By: Robert Minsk (rminsk)
Date: 2001-06-22 17:48
Message:
Logged In: YES
user_id=132786
After some more investigation it seems to be a CPU
pipelining bug in the optimizer.
#define CONVERT_TO_DOUBLE(obj, dbl) \
if (PyFloat_Check(obj)) \
dbl = PyFloat_AS_DOUBLE(obj); \
else if (convert_to_double(&(obj), &(dbl)) < 0) \
return obj;
PyFloat_Check is a macro as well is PyFloat_AS_DOUBLE. Due
to the CPU pipelining PyFloat_AS_DOUBLE (a cast to a double)
is always being called. What happens is non-float objects
that are not 8-byte aligned are being cast to a double.
I am trying to figure out if I can reorder the code to not
cause this pipelining issue. I will also see if I can
somehow force a nop after PyFloat_Check. I will also open a
bug with SGI.
----------------------------------------------------------------------
Comment By: Robert Minsk (rminsk)
Date: 2001-06-21 20:42
Message:
Logged In: YES
user_id=132786
Thank you tim_one for the hint... I still trying to track it
down but
changing Include/intobject.h PyIntObject to include memory
alignment pragmas seem to be the trick. On the SGI I've
changed it to
#pragma pack(8)
typedef struct {
PyObject_HEAD
long ob_ival;
} PyIntObject;
#pragma pack(0)
This is only a hack until I find a way to get the proper
alignment. I'm begining to wonder if anywhere in the float
code something is trying to cast a int object to a float
object.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-06-21 19:52
Message:
Logged In: YES
user_id=31435
Robert, let us know if you find it! There's always *some*
optimization bug on SGI boxes, but this one is particularly
noxious.
Someone on c.l.py suggested it may be a problem with Python
accessing a double at an unaligned (for the platform)
memory address. They didn't follow up, so I don't know
whether that's the case, but if it is we would consider it
a bug in Python (we try to stick to std C, so if there's an
unaligned access it's a bug in our coding -- but I don't
see anything like that by eyeball).
----------------------------------------------------------------------
Comment By: Robert Minsk (rminsk)
Date: 2001-06-21 19:41
Message:
Logged In: YES
user_id=132786
Python 2.1 core dumps on any
<float> <operator> <int>
using the 7.3.1.2m compilers with -O2 or greater. If the
file Objects/floatobject.c is compiled with -O1 everything
seems fine. It is core dumping in the macro
CONVERT_TO_DOUBLE. It seems the call stack gets corrupted.
I'm trying to find a workaround besides -O1.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435026&group_id=5470