gh-153144: Avoid checking errno for atan2

[hpkfft]

The C23 standard states that for atan2 and atan2pi:

A domain error may occur if both arguments are zero.
A range error occurs if x is positive and nonzero y/x is too close to zero.

Since Python should not raise ValueError in either of these cases (i.e., when both arguments are zero or when the computation underflows), this PR avoids checking errno when calling these trig functions. As a bonus, math.atan2() is about 4% faster.

• Issue: ValueError for math.atan2(0.0, 0.0) and cmath.phase(0.0) using icx #153144

---

The statement about range error in the standard should, I think, be interpreted as:

A range error occurs if (x is positive) and (y/x is nonzero) and (y/x is too close to zero).

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[hpkfft]

If this PR is merged, it looks to me like #146402 can (and should) be reverted.

[skirpichev]

No, I doubt that this is a right approach. We must handle error in same way for all libm functions.

Perhaps, m_atan2() (like m_log1p() we have currently) could be restored (see #122681) to workaround broken platform functions.

[hpkfft]

We must handle error in same way for all libm functions.

The mathmodule currently has 3 ways of handling 1-argument libm functions:

• Functions that cannot overflow (e.g., acos, atan) use math_1(arg, func, /*can_overflow=*/0, err_msg)
• Functions that can overflow (e.g., cosh, exp) use math_1(arg, func, /*can_overflow=*/1, err_msg)
• Functions that are known to set errno properly (e.g., erf, gamma) use math_1a(arg, func, err_msg)

Maybe it's not so bad to have math_2ne for 2-argument functions that are known not to need error checking (e.g., atan2) as well as the current math_2 (for the others).

[skirpichev]

Perhaps, we could modify math_2() helper to check that errno!=EDOM, if inputs and output are finite. When domain error occurs - result should be nan.

But I think that a little wrapper for libm's atan2 is better, if we are going to add some workaround for the given issue.

[skirpichev]

Please revert unrelated changes.

[hpkfft]

@vstinner, can you look at this at your convenience?
I anticipate that this PR will also fix Solaris to return the correct results (#138573), so the relevant math/cmath tests will not need to be skipped on that platform. Please advise whether I should revert #146402 as part of this PR. If so, I'll do that and would then ask you to run on the buildbots.

[vstinner]

If this PR is merged, it looks to me like #146402 can (and should) be reverted.

I would prefer to update tests for Solaris in the same PR.

[vstinner]

I expected a test_cmath failure when this code path is removed. Is it because glibc math library doesn't errno in this case?

[hpkfft]

Yes. With the exception of the Intel and Solaris math libraries, errno is not set in this case by any math library that Python cares about. I say this because test_phase in Lib/test/test_cmath.py has asserted that return values are correct since Python 3.14, and nobody has complained. If errno were set by the C math library, the unittest would fail with ValueError: math domain error.

🌱 Some math libraries (e.g., musl) don't set errno for anything, so Python cannot rely on errno for detecting overflow or invalid. I would think that errno checking can be removed everywhere....

[skirpichev]

You also could use new helper function for copysign.

On another hand, I would prefer just remove errno stuff from math_2(), per #156145. It should be possible for all two-argument functions: atan2, atan2pi, copysign, remainder and fmod (which could utilize same wrapper).

[hpkfft]

You also could use new helper function for copysign.

My thinking is only to do what is necessary to fix the bug (the incorrect results when building with Intel or Solaris math libraries). Then, I would recommend applying this fix to Python 3.14 and 3.15. With that in mind, I don't want to make any enhancements that are not necessary to fix the reported bug.

On another hand, I would prefer just remove errno stuff from math_2(), per #156145. It should be possible for all two-argument functions: atan2, atan2pi, copysign, remainder and fmod (which could utilize same wrapper).

Yes, 156145 can have a more ambitious goal.

Can you trigger the buildbots to run this PR? I am not able to check myself that it works on Solaris. (I do think it will work based on what I read in the Solaris bug report.)

[skirpichev]

My thinking is only to do what is necessary to fix the bug

Then we loose chance of using new helper function for copysign().

Can you trigger the buildbots to run this PR?

!buildbot Solaris

[skirpichev]

!buildbot Solaris

[bedevere-bot]

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

Results will be shown at:

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

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

The builders matched are:

• SPARCv9 Oracle Solaris 11.4 PR

[hpkfft]

Then we loose chance of using new helper function for copysign().

OK, I'll add that commit tomorrow. Since it will be a separate commit, it can easily be reverted (or skipped when squashing all the commits before the final merge). The same is true for the comments Victor requested--they're in their own separate commit.

[hpkfft]

I'm happy to see that the math and cmath tests pass on Solaris.
As requested, I added commit to use FUNC2NE for copysign.

[hpkfft]

Hi @StanFromIreland,

Can you please advise whether I should create a separate bug report for an issue @serhiy-storchaka observed:

Python 3.13.5 (main, Jul 15 2026, 20:25:40) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.phase(complex(1e300, 1e-320))
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    cmath.phase(complex(1e300, 1e-320))
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
OverflowError: math range error

or whether #153144 can be updated with this extra information?
This PR, by not checking errno, fixes this bug too (correctly returning 0.0).

Note that #153144 affects the current version of the Intel math library and the Solaris math library, so it's correctly labelled OS-unsupported.
The OverflowError bug affects any math library that sets errno when z.imag/z.real underflows to zero (e.g., GNU).

[vstinner]

Hum. It's uneasy for me to take a decision on this change. The bug report is about supporting Intel compiler (icx) which sets errno for atan2() and phase(). But the PR also changes cmath.phase() behavior on overflow and underflow of imag/real.

I'm not sure if cmath.phase(complex(1e300, 1e-320)) should raise an OverflowError (current behavior) or just return 0.0. I failed to find the rationale for changing phase() behavior.

[hpkfft]

But the PR also changes cmath.phase() behavior on overflow and underflow of imag/real.

Python already returns the correct result, pi/2, if imag/real OVERflows (using 3.13 as shipped by Debian):

>>> cmath.phase(complex(1E-320, 1E300))
1.570796326794896

This PR changes cmath.phase() behavior on UNDERflow of imag/real (bug observed in #155527 (comment)).

The C standard in 7.3.9.1 says:

The carg functions compute the argument (also called phase (which is an angle)) of z, with a branch cut along the negative real axis.
The carg functions return the value of the argument in the interval [−π, +π].

Note that there's no possibility of overflow--the result is bounded. (The implementation may or may not actually perform a floating-point division of imag/real, but that's an implementation detail, and whether or not some intermediate calculation overflows must not affect what the user observes.)

There is the possibility of underflow. The infinitely precise result of cmath.phase(complex(1e300, 1e-320)) is very close to zero, but is not exactly zero:

>>> z = gmpy2.mpc(1e300, 1e-320)
>>> z
mpc('1.0000000000000001e+300+9.9998886718268301e-321j')
>>> gmpy2.phase(z)
mpfr('9.9998886718268287e-621')

The result is too small to be represented in double precision, so it underflows to 0.0.

Python does not raise an exception on underflow, only on overflow. For example:

>>> math.exp(-1000)
0.0
>>> math.exp(1000)
Traceback (most recent call last):
  File "<python-input-14>", line 1, in <module>
    math.exp(1000)
    ~~~~~~~~^^^^^^
OverflowError: math range error

I created the bug report because existing tests were failing when building Python with the Intel math library. I made this PR to ignore errno because I could see no reason for checking it, and I believed that not checking it was always correct. I did not stop to consider that the old code (checking errno) led to more Python bugs. After reading Serhiy's comment, I added tests to this PR and updated the NEWS.