GeezerVison

cc @skirpichev

Example of failure with 32-bit float on x86:

float_pack:  {0x00,0x00,0x00,0x20,0xdc,0xd1,0xf2,0x7f}
Float_Pack4: {0x00,0x00,0x00,0x20,0xdc,0xd1,0xfa,0x7f}

0xf2 in _testcapi.float_pack() becomes 0xfa in PyFloat_Pack4(). The sNaN becomes a qNaN just by the calling convention, there is nothing that we can do.

There is a similar problem with PyFloat_Pack2().

I'm not sure why it works with PyFloat_Pack8().

I'm not sure why it works with PyFloat_Pack8().

Hmm, my tests show that on 32-bit sNaN becomes qNaN after calling. Are you sure that size=8 tests works?

!buildbot x86

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

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133155%2Fmerge

The command will test the builders whose names match following regular expression: x86

The builders matched are:

• x86 Debian Non-Debug with X PR
• x86-64 MacOS Intel NoGIL PR
• x86-64 macOS PR
• x86-64 MacOS Intel ASAN NoGIL PR
• x86 Debian Installed with X PR

Are you sure that size=8 tests works?

It works on Python built with gcc -O3. But it failed on the x86 Debian buildbot :-(

It works on Python built with gcc -O3

I guess, optimizer avoid using FPU registers

As a quick fix I suggest to disable testing in 32-bit mode. And also reduce number of tests as suggested, 10 should be enough.

In a follow-up PR I'll do cleanup. Probably float_set_snan() is not helpful, as well as other attempts to workaround passing of sNaN.

@skirpichev: I rewrote my PR to simply skip the test on x86 Debian, but not skip the test on x86 Windows. Please review the updated PR.

!buildbot x86 Debian

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

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133155%2Fmerge

The command will test the builders whose names match following regular expression: x86 Debian

The builders matched are:

• x86 Debian Installed with X PR
• x86 Debian Non-Debug with X PR

Merged, thanks for the review.

Sadly, I don't think that we can work around "compiler bugs" if sNaN becomes qNaN as soon as we call a simple function taking a double. Skipping the test sounds like the only option.