bpo-46640: Py_NAN now uses the C99 NAN constant

[vstinner]

Building Python now requires a C99 <math.h> header file providing the
NAN constant.

https://bugs.python.org/issue46640

[corona10]

lgtm

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @vstinner for commit bd6b0bcb748514702feb5f542f718fa97b6d9d39 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[vstinner]

test_urllib2 failed on many buildbots: https://bugs.python.org/issue36019

[corona10]

test_urllib2 failed on many buildbots

That's true :(

[vstinner]

I updated my PR:

• Add a single Build NEWS entry -remove the C API entry).
• Clarify that it remains possible to build Python without NaN support: define Py_NO_NAN in pyconfig.h.
• Use __builtin_nan("") if available (GCC, clang).

[vstinner]

Nitpick: isinf, isnan and isfinite are macros, not functions.

For Python, a macro or function is the same. This change with this NEWS entry is already released: was moved to NEWS.d/3.11.0a2.rst. I prefer to leave it unchanged. Or do you think that it matters?

[vstinner]

I looked at the machine code generated by clang -O3 on Fedora 35 x86-64 (clang 13.0.0). For this mathmodule.c function:

static double
m_atan2(double y, double x)
{
if (Py_IS_NAN(x) || Py_IS_NAN(y))
return Py_NAN;
...
}

The return Py_NAN; becomes:

=> 0x00007fffea51a2a2 <m_atan2+98>:	movsd xmm0,QWORD PTR [rip+0x1e1e] # 0x7fffea51c0c8
0x00007fffea51a2aa <m_atan2+106>:	ret

The movsd instruction sets xmm0 to:

(gdb) p $xmm0
$1 = {
v8_bfloat16 = {0, 0, 0, nan(0x78), 0, 0, 0, 0},
v4_float = {0, nan(0x780000), 0, 0},
v2_double = {nan(0x8000000000000), 0},
v16_int8 = {0, 0, 0, 0, 0, 0, -8, 127, 0, 0, 0, 0, 0, 0, 0, 0},
v8_int16 = {0, 0, 0, 32760, 0, 0, 0, 0},
v4_int32 = {0, 2146959360, 0, 0},
v2_int64 = {9221120237041090560, 0},
uint128 = 9221120237041090560
}

It seems like clang creates a private variable at 0x7fffea51c0c8 with v2_double = {nan(0x8000000000000), 0}, to at the end, it's a single 64-bit MOV instruction to write directly to the SSE XMM0 register (the MOV also sets xmm0.v2_double[1] to 0).

[vstinner]

gcc -03 (GCC 11.2.1) produces similar code for return Py_NAN;:

0x00007fffea5177d8 <math_atan2+728>: movsd xmm0,QWORD PTR [rip+0x7790] # 0x7fffea51ef70

[vstinner]

Using gcc -O3, #define Py_NAN (__builtin_nan("")) and #define Py_NAN ((double)NAN) produce the same machine code and use the same number (nan(0x8000000000000)).

[vstinner]

The Windows SDK defines these macros in ucrt/corecrt_math.h:

#ifndef _HUGE_ENUF
#define _HUGE_ENUF 1e+300 // _HUGE_ENUF*_HUGE_ENUF must overflow
#endif
#define INFINITY ((float)(_HUGE_ENUF * _HUGE_ENUF))
#define NAN ((float)(INFINITY * 0.0F))

ref: https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16299.0/ucrt/corecrt_math.h

It's similar to Python current definition of Py_NAN (simplified code):

#define Py_HUGE_VAL HUGE_VAL
#define Py_NAN (Py_HUGE_VAL * 0.)

Py_HUGE_VAL and Py_NAN are double.

[mdickinson]

It turns out that building under Py_NO_NAN doesn't actually work right now. I've opened an issue: https://bugs.python.org/issue46656

[mdickinson]

With this change, the comment about INF*0 or INF/INF working is out of date; that sentence should probably be removed.

[mdickinson]

Needs a comment update, but otherwise LGTM. It turns out that Py_NO_NAN doesn't actually work right now, but that's a separate issue.

[vstinner]

Merged. Thanks for the review @mdickinson!