Program received signal SIGFPE, Arithmetic exception.
0x0000000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219

(this is actually due to _PyFloat_Unpack8)

Logged In: YES 
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080, 
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387             else if (!Py_IS_FINITE(i)) {

Logged In: YES 
user_id=139309

More fun in test_long

Program received signal SIGFPE, Arithmetic exception.
0x000000012003972c in float_richcompare (v=0x120397080, 
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387             else if (!Py_IS_FINITE(i)) {

Logged In: YES 
user_id=33168

Try adding the -mieee flag when compiling.  That should fix
the problem.  It looks like we only set this for OSF
platforms.  It should probably be set for all Alpha platforms.  

See: 
http://mail.python.org/pipermail/python-dev/2006-March/063219.html

There are some current math and cmath test failures on the Debian alpha 
buildbots (2.6 and 3.0), and I think there's a good possibility that 
adding -mieee to BASECFLAGS would fix these.

I'm struggling to find the right way to do this in configure.in.
I've found the GCC specific section for BASECFLAGS (around line 800), but 
I don't know how to write a test for an alpha CPU (rather than a test for 
a specific operating system).  Any hints or pointers?

I think `uname -m` will be equal to "alpha" in this case.  There are
several uses of `uname -m` in configure.in.  You might need to add a
new section.  It might also be possible to clean up various special
cases to make a generic `uname -m` section.  I didn't look too closely
though.

-m is the machine type

BTW, -m works on Tru64.  I also tested on Ubuntu and it reported
x86_64, on Debian it reported sparc.  On OSX.4, it reported "Power
Macintosh".

Okay---I've added -mieee to BASECFLAGS in r62499, when uname -m reports 
alpha* and when gcc is the compiler;  I've also added a configure message 
that simply reports the output of uname -m, to aid debugging in case 
anything funny happens.

With luck, this should fix the problems reported by Bob Ippolito, as well 
as the current test_math and test_cmath failures.

Bob, if you're still listening, are you in a position to check whether 
this change fixes the failures you reported?

Adding -mieee didn't fix the math and cmath problems.  Should I revert 
the change in r62499, or leave it in?  It seems to me that having -mieee 
is a good thing on the whole.  The main reason to not want IEEE 754 
conformance would be speed.

It looks like the math and cmath failures are due to libm behaviour;  
either (1) libm is making no attempt to be IEEE compliant, or (2) it's 
setting errno in places that it shouldn't, or (3) it's trying to be IEEE 
compliant but is buggy.  I'm not sure how to proceed.  Would it be okay 
to check in some temporary autoconf tests to help identify the source of 
the failures, and remove them later?

Bob, can you still reproduce the originally reported SIGFPE?

I don't even recall where I had access to a FreeBSD 6.0 Alpha machine, 
sorry.

No problem!  I'll close this as out of date, then.