[Python-Dev] --with-fpectl changes the CPython ABI

[Nathaniel Smith]

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.turnon_sigfpe()
>>> np.longdouble(1) / np.longdouble(0)
Fatal Python error: Unprotected floating point exception

Current thread 0x00007fea57a9f700 (most recent call first):
  File "<stdin>", line 1 in <module>
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