Bug 2050736
Summary: | NaN regression between gcc-12.0.1-0.4.fc36 and gcc-12.0.1-0.5.fc36 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | aoliva, code, dmalcolm, fweimer, jakub, jwakely, law, mpolacek, msebor, nickc, pviktori, sipoyare, thrnciar, vstinner |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | gcc-12.0.1-0.6.fc36 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-02-06 18:11:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2050761 |
Description
Miro Hrončok
2022-02-04 14:37:08 UTC
I see one NaN related change in the -0.4.fc36 to -0.5.fc36 diff, in particular https://gcc.gnu.org/PR95115 fix. But it has been backported into gcc 11 and 10 already. My python is a little bit rusty, does the above mean that also say import cmath, math NAN = float('nan') print(math.isnan(abs(complex(NAN, -2.3)))) now prints False instead of True? (In reply to Jakub Jelinek from comment #2) > My python is a little bit rusty, does the above mean that also say > import cmath, math > NAN = float('nan') > print(math.isnan(abs(complex(NAN, -2.3)))) > now prints False instead of True? Yes. In order to tell, I've rebuilt python3.11-3.11.0~a5-1.fc36 --without tests with gcc-12.0.1-0.5.fc36: <mock-chroot> sh-5.1$ python3.11 Python 3.11.0a5 (main, Feb 4 2022, 00:00:00) [GCC 12.0.1 20220202 (Red Hat 12.0.1-0)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cmath, math >>> NAN = float('nan') >>> math.isnan(abs(complex(NAN, -2.3))) False The previous build, with gcc-12.0.1-0.4.fc36: <mock-chroot> sh-5.1$ python3.11 Python 3.11.0a5 (main, Feb 4 2022, 00:00:00) [GCC 12.0.1 20220129 (Red Hat 12.0.1-0)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cmath, math >>> NAN = float('nan') >>> math.isnan(abs(complex(NAN, -2.3))) True gcc-12.0.1-0.4.fc36: >>> abs(complex(NAN, -2.3)) nan gcc-12.0.1-0.5.fc36: >>> abs(complex(NAN, -2.3)) 0.0 gcc-12.0.1-0.4.fc36: >>> NAN = float("nan") >>> 0j/complex(NAN, NAN) (nan+nanj) gcc-12.0.1-0.5.fc36: >>> NAN = float("nan") >>> 0j/complex(NAN, NAN) 0j There is also: >>> math.atan2(0., NAN) 0.0 >>> math.hypot(NAN) 0.0 >>> math.hypot(NAN, NAN) 0.0 But I was unable to reproduce the math.isclose(NAN, NAN) == True thing :/ I reported the issue to GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Thanks, I'll test the fix and if all goes well, will include it in tomorrow's rawhide gcc build. Note, as mentioned on the gcc-patches mailing list, you still should change python too, because unlike before GCC will no longer fold that Inf * 0. to NaN at compile time (in order to raise an exception, except for -ffast-math or -fno-trapping-math). So in #if !defined(Py_NAN) && !defined(Py_NO_NAN) # if !defined(__INTEL_COMPILER) # define Py_NAN (Py_HUGE_VAL * 0.) ... better try something like: # ifdef __has_builtin # if __has_builtin (__builtin_nan) # define Py_NAN __builtin_nan ("") # endif # endif # ifdef Py_NAN # elif !defined(__INTEL_COMPILER) # define Py_NAN (Py_HUGE_VAL * 0.) ... (untested). > You still should change python too, because unlike before GCC will no longer fold that Inf * 0. to NaN at compile time Was it the case previously? Anyway, because of this bug, I already proposed a PR to modify PY_NAN to implement it as: // Use C99 "NAN" constant: quiet Not-A-Number (when supported) #define Py_NAN NAN => https://github.com/python/cpython/pull/31134 FEDORA-2022-fba9d09417 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fba9d09417 FEDORA-2022-fba9d09417 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. Building python3.11-3.11.0~a5-1.fc36 for rawhide Created task: 82493152 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=82493152 Thanks, it appears fixed. As for #define Py_NAN NAN, yeah, that is certainly an option, but depends on if it would be the only reason why python requires a C99 compiler. If it already uses e.g. declarations in for loop inits, then it is reasonable to assume even NAN, but if the whole codebase is C89 compilable, then one choice is also define Py_NAN to NAN if NAN is defined and fallback to what it has been doing previously. Your choice... > https://github.com/python/cpython/pull/31134 I merged my PR: https://github.com/python/cpython/commit/54842e4311bb0e34012d1984b42eab41eeeaea6a My final change also prefers __builtin_nan("") if it's available, since NAN must be casted to (double): Py_NAN must be a double. I don't plan to backport my change since it adds new requirements to build Python and that's not acceptable in a bugfix (3.9.x and 3.10.x) release. It's ok if Python computes HUGE_VAL*0 at runtime, Python is not very efficient for floating point operations, because of boxing/unboxing in PyObject (PyFloatObject) and the the slow bytecode evaluation. I mean HUGE_VAL*0 is not going to be *the* performance bottleneck of Python ;-) > As for #define Py_NAN NAN, yeah, that is certainly an option, but depends on if it would be the only reason why python requires a C99 compiler. Python requires a C99 compiler to build since Python 3.6: https://www.python.org/dev/peps/pep-0007/#c-dialect |