🤖 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.

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

test_urllib2 failed on many buildbots

That's true :(

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).

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?

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).

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

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

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)).

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.

Merged. Thanks for the review @mdickinson!