GeezerVison

!buildbot wasi

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit c95e6f9 🤖

Results will be shown at:

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

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

The builders matched are:

• wasm32-wasi Non-Debug PR
• wasm32-wasi PR
• wasm32 WASI 8Core PR

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

Results will be shown at:

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

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

buildbot/wasm32 WASI 8Core PR — Build done.
buildbot/wasm32-wasi Non-Debug PR — Build done.
buildbot/wasm32-wasi PR — Build done.

Nice, test_math pass on WASI buildbots.

cc @serhiy-storchaka

test_fma_zero_result() failed on Android and FreeBSD.

buildbot/AMD64 Android PR

FAIL: test_fma_zero_result (test.test_math.FMATests.test_fma_zero_result)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/user/0/org.python.testbed/files/python/lib/python3.14/test/test_math.py", line 2814, in test_fma_zero_result
    self.assertIsNegativeZero(math.fma(x-y, x+y, -z))
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/user/0/org.python.testbed/files/python/lib/python3.14/test/test_math.py", line 2919, in assertIsNegativeZero
    self.assertTrue(
    ~~~~~~~~~~~~~~~^
        value == 0 and math.copysign(1, value) < 0,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        msg="Expected a negative zero, got {!r}".format(value)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
AssertionError: False is not true : Expected a negative zero, got 0.0

buildbot/AMD64 FreeBSD PR

FAIL: test_fma_zero_result (test.test_math.FMATests.test_fma_zero_result)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/pull_request.ware-freebsd/build/Lib/test/test_math.py", line 2814, in test_fma_zero_result
    self.assertIsNegativeZero(math.fma(x-y, x+y, -z))
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/buildbot/buildarea/pull_request.ware-freebsd/build/Lib/test/test_math.py", line 2919, in assertIsNegativeZero
    self.assertTrue(
    ~~~~~~~~~~~~~~~^
        value == 0 and math.copysign(1, value) < 0,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        msg="Expected a negative zero, got {!r}".format(value)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
AssertionError: False is not true : Expected a negative zero, got 0.0

AMD64 Windows11 Bigmem PR

Unrelated failure: test_bigmem failed.

buildbot/iOS ARM64 Simulator PR

Unrelated failure:

1 test altered the execution environment (env changed):
    test_interpreters

Test failing on Android and FreeBSD:

        # Corner case where rounding the multiplication would
        # give the wrong result.
        x = float.fromhex('0x1p-500')
        y = float.fromhex('0x1p-550')
        z = float.fromhex('0x1p-1000')
        self.assertIsNegativeZero(math.fma(x-y, x+y, -z))
        self.assertIsPositiveZero(math.fma(y-x, x+y, z))
        self.assertIsNegativeZero(math.fma(y-x, -(x+y), -z))
        self.assertIsPositiveZero(math.fma(x-y, -(x+y), z))

z is not zero in this case.

Proposed patch affects only case when the last argument (z) is zero, which is the case for most tests in this function. Maybe we can factor out other tests to a separate function (and then skip them).

Netbsd failure also seems related to z!=0 case. Not sure about WASI.

!buildbot wasi

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

Results will be shown at:

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

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

The builders matched are:

• wasm32-wasi Non-Debug PR
• wasm32-wasi PR
• wasm32 WASI 8Core PR

!buildbot FreeBSD

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

Results will be shown at:

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

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

The builders matched are:

• AMD64 FreeBSD15 PR
• AMD64 FreeBSD PR
• AMD64 FreeBSD Refleaks PR
• AMD64 FreeBSD14 PR

!buildbot Android

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

Results will be shown at:

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

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

The builders matched are:

• AMD64 Android PR
• aarch64 Android PR

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

Results will be shown at:

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

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

It looks this PR does not fix the real issue. It only handles one specific case z == 0, but does not handle zillions more special cases when x * y is too close to -z. There may also be many cases when the result of fma() is not zero, but not precise. Handling this only for z == 0 can make all worse, because the function will no longer be monotonic.

To handle all cases, we need to implement fma() from scratch, using floating point with 106-bit or like mantissa. It was decided to not do it when this function was added.

It looks this PR does not fix the real issue.

Well, linked issue is a real one. Though, I expected more such cases. (Maybe WASI too?)

#131071 is an alternative. BTW, I think that test_fma_zero_result() could be split in that pr as well.

It only handles one specific case z == 0

That's true. Only simple workarounds were considered, not implementation of fma() from scratch.

There may also be many cases when the result of fma() is not zero, but not precise.

Maybe. But in this case our test suite lacks tests to trigger this. I think that at least failure with musl C stdlib may be related only to arguments with special values.

@serhiy-storchaka is against this workaround: #131134 (comment). I abandon this approach.