Created attachment 1810756 [details] GCC Compilation error The GCC compiler fails exclusively on ppc64le (which is the only PPC architecture variant we build for in Fedora) This issue exists on all Fedora releases (F33..Rawhide) The compilation error is: | /builddir/build/BUILD/mysql-8.0.26/unittest/gunit/innodb/ut0new-t.cc:58:63: | error: '(2.00416836000897277799610805135016e-292l + 1.0e+0l)' | is not a constant expression | | 58 | static constexpr T INIT_VAL = std::numeric_limits<T>::min() + 1; (The whole message can be found in the attachment) And the C++ expression can be seen here: https://github.com/mysql/mysql-server/blob/8.0/unittest/gunit/innodb/ut0new-t.cc#L58 I've asked around and found out that GCC has always had a problem when it comes to constant expressions of double double format on PPC. Here's an explanation from the Red Hat engineer specialised on PPC architecture: | The problem with constant evaluation of IBM double double format remains, | the problem is that GCC internally represents constants of that type as | 106bit mantissa and otherwise similar to IEEE formats, but that is not how | it behaves, it has terrible numerical properties of varying mantissa length | with all zeros or all ones forced in between if the mantissa is longer than | 106 bits (can be up to ~2100 bits or so). | So, to properly handle it during constant evaluation, the compiler would | need to instead represent it the way it actually is represented under the | hood, i.e. a sum of two doubles, and override everything that works with | those numbers to handle it that way with the various canonicalization rules | on how it behaves on arithmetics. As ppc64le is trying to move away | from this format to a standard IEEE quad, that significant effort is not | worth it. The general advice is to avoid using constexpr in such cases in programs built by GCC for the PPC architecture. -- The issue appeared with the 8.0.26 release. I tried to find a commit between the 8.0.25 release and the 8.0.26 release that might cause this to be an issue all of sudden. I tried to revert the following commits, which affects the nearby code: 77cc646c9e4c9a39429311b89e121e4334718f32 9620c59d44a71e3fac22d1698acea95cad170f4c b04ce7e067b495ab212162a4e23db5d6fc0b5da7 d6a71884152f4744ce73b7a2523a2340c4cd3cbe db6f9fd1169a5a774143edb199c2fa179d95fc1c but the issue remained. The used expression isn't new. As far as I can tell, it has been added in 12/2019 by this commit: https://github.com/mysql/mysql-server/commit/ede6cd9d365ec1803decd60db3ff707c928997c1 but haven't caused the compile time issue until 8.0.26 release. -- Just for reference, a similar issue existed in 2018: https://bugzilla.redhat.com/show_bug.cgi?id=1538817 ^ links to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88204 However in our case it might be better to focus just on finding the trigger and dealing with that.
hi! The origin of the problem is that after https://github.com/mysql/mysql-server/commit/93cb5899f9190ce9ef095c3b5472da071e9f479c#diff-af2db7f3bd3122eeaa50ef7af702c82a81a81abd80380f56e82b91d92cc93590 Bug #32512077 BUNDLE GOOGLETEST SOURCE unit tests (which is something different from MTR tests) are built by default. This was not the case for MySQL 8.0.25 in Fedora, hence code above has never been built on Fedora before. Simple workaround is revert to 8.0.25 behaviour by adding cmake option: -DWITH_UNIT_TESTS=0 (at least on problematic platforms) or disable this specific unit test. Such change will have no side effects on shipped binaries, unit tests is standalone bins which is not shipped at all.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Link to commit fixing this issue: https://src.fedoraproject.org/rpms/community-mysql/c/e6208748d4cab839241ba89f69a1c3b6183a0b21?branch=rawhide
(In reply to Lukas Javorsky from comment #3) > Link to commit fixing this issue: I wouldn't really say "fixing" but rather use term "workaround of this issue". I'd like to minimise the workaround impact and re-enable the unit tests on the aches where it works. However I encountered another issue I haven't time to deal with so I hit two birds with one stone by disabling it entirely :) I plan to leave this issue in MODIFIED state for a while, before I get back to it and continue with what I described above.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.