classification
Title: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.1, Python 2.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: bob.ippolito, mark.dickinson, nnorwitz
Priority: normal Keywords:

Created on 2006-05-27 15:21 by bob.ippolito, last changed 2009-04-27 16:33 by mark.dickinson. This issue is now closed.

Messages (11)
msg60924 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2006-05-27 15:21
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)
msg60925 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2006-05-27 16:12
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)) {
msg60926 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2006-05-27 16:12
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)) {
msg60927 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-06-01 06:02
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
msg65724 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-04-24 14:01
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?
msg65771 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2008-04-25 03:39
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".
msg65792 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-04-25 16:17
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?
msg65974 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-04-29 17:34
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?
msg86670 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-27 15:13
Bob, can you still reproduce the originally reported SIGFPE?
msg86672 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2009-04-27 15:38
I don't even recall where I had access to a FreeBSD 6.0 Alpha machine, 
sorry.
msg86676 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-27 16:33
No problem!  I'll close this as out of date, then.
History
Date User Action Args
2009-04-27 16:33:33mark.dickinsonsetstatus: open -> closed
resolution: out of date
messages: + msg86676
2009-04-27 15:38:53bob.ippolitosetmessages: + msg86672
2009-04-27 15:24:48mark.dickinsonsetassignee: mark.dickinson
2009-04-27 15:13:19mark.dickinsonsetmessages: + msg86670
2009-04-27 01:34:31ajaksu2settype: behavior
versions: + Python 2.6, Python 3.1, - Python 2.5
2008-04-29 17:34:06mark.dickinsonsetmessages: + msg65974
2008-04-25 16:17:31mark.dickinsonsetmessages: + msg65792
2008-04-25 03:39:27nnorwitzsetmessages: + msg65771
2008-04-24 14:01:01mark.dickinsonsetnosy: + mark.dickinson
messages: + msg65724
2006-05-27 15:21:36bob.ippolitocreate