[Python-Dev] --with-fpectl changes the CPython ABI (original) (raw)

Nathaniel Smith njs at pobox.com
Mon Jan 2 03:27:42 EST 2017

On Sun, Dec 25, 2016 at 5:55 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 25 December 2016 at 09:48, Nathaniel Smith <njs at pobox.com> wrote:

Or maybe make it so that even no-fpectl builds still export the necessary symbols so that yes-fpectl extensions don't crash on import? (This has the advantage that it can be done in a point release...) This seems like a sensible thing to do in 3.6, 3.5 and 2.7 regardless of what happens in 3.7. For 3.7, I don't understand the trade-offs well enough to have a strong opinion, but dropping the feature entirely does seem reasonable - folks that want fine-grained floating point exception control these days are likely to be much better served by the decimal module, or one of the third party computing libraries (numpy, gmpy, sympy, etc).

I looked into this a bit more. I think the way it's supposed to work is that normally, various operations in Python might return inf or nan, but if you call fpectl.turnon_sigfpe() then they switch to raising exceptions instead. But AFAICT the fpectl module:

  1. is totally broken on major platforms: There doesn't seem to be any implementation at all for MacOS. On x86/x86-64 Linux it works by fiddling with the x87 control word directly... which is okay for traditional x86 with SSE disabled, but on x86-64, or x86 with SSE enabled, then there are two separate floating point units on the processor (the old x87 FPU, and the new SSE unit), and which one gets used for any given operation is up to the C compiler. So on Linux, whether fpectl actually affects any given floating point operation is dependent on basically the phase of the moon. This is pretty bad.

  2. doesn't seem to actually accomplish anything even when it does work: Back in the old days, math.exp(1000) apparently returned inf (there's a REPL transcript showing this at the top of the fpectl documentation). But nowadays math.exp raises an exception in cases where it used to return inf, regardless of fpectl. I haven't been able to find any cases where fpectl actually... does anything?

  3. ...except that it does break numpy and any other code that expects the default IEEE-754 semantics: The way fpectl works is that it twiddles with the FP control word, which is a thread-global variable. After you call turnon_sigfpe(), then any floating point code in that thread that happens to generate a nan or inf instead triggers a SIGFPE, and if the code isn't specifically written to use the PyFPE_* macros then this causes a process abort. For example:

~$ python Python 3.5.2+ (default, Dec 13 2016, 14:16:35) [GCC 6.2.1 20161124] on linux Type "help", "copyright", "credits" or "license" for more information.

import numpy as np np.longdouble(1) / np.longdouble(0) main:1: RuntimeWarning: divide by zero encountered in longdouble_scalars inf import fpectl fpectl.turnonsigfpe() np.longdouble(1) / np.longdouble(0) Fatal Python error: Unprotected floating point exception

Current thread 0x00007fea57a9f700 (most recent call first): File "", line 1 in zsh: abort python ~$

(I'm using np.longdouble to work around the Linux SSE bug -- using long double forces the calculations to be done on the x87 unit. On Windows I believe it would be sufficient to just do np.array(1.0) / np.array(0.0).)

So I guess that yeah, my suggestion would be to drop this feature entirely in 3.7, given that it's never been enabled by default and has been largely broken for years. Or do we still need a full deprecation cycle?

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list