Initial (minor) issue was that fpectl.c issues an unused 
variable warning compiling on Linux Itanium (ia64).  On 
Itanium the _FPU_SETCW(cw) macro is a stub which 
does not reference cw.  Turns out fpectl.c issues an 
explicit write of 0x1372 to the fpu control register via this 
macro, if found in the headers. With some further 
digging, here's the story as it seems on Linux:

(1) fpectl.tex is out of date with respect to current 
behavior.  Here's an excerpt (markup removed):
+++++++
some floating point operations produce results that 
cannot be expressed as a normal floating point value.
For example, try

>>> import math
>>> math.exp(1000)
inf
>>> math.exp(1000) / math.exp(1000)
nan
+++++++
However, current Python behaves like this:

>>> math.exp(1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error

(2) the fpectl module has no effect on ia64, where it's 
simply a stub. Behavior on other platforms such as 
Sparc, powerpc, etc might be unpredictable.

(3) on i386, use of fpectl will cause Python to crash:

Python 2.2.1 (#1, Jul 29 2002, 15:14:33)
[GCC 3.2 (Mandrake Linux 9.0 3.2-0.1mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import fpectl
>>> import math
>>> fpectl.turnon_sigfpe()
>>> math.exp(1000)
Fatal Python error: Unprotected floating point exception
Aborted
$

(4) Linux/glibc documentation suggests that the 
preferred interface for manipulating IEEE floating point 
exception and rouding behavior is with C99 standard 
routines fesetround() and fesetenv().

Logged In: YES 
user_id=11375

The fpectl module has been removed from the setup.py in CVS and in Python 2.2.2, so it will no longer be compiled automatically. Thanks for pointing this out.

Marking this bug as closed; figuring out a new interface for FPE control will probably need a PEP.