Bug 1989847

Summary: community-mysql: FTBFS exclusively on the ppc64le arch due to use of "constexpr" and GCC
Product: [Fedora] Fedora Reporter: Michal Schorm <mschorm>
Component: community-mysqlAssignee: Michal Schorm <mschorm>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 35CC: damien.ciabrini, hhorak, ljavorsk, mbayer, mkocka, mmuzila, mschorm, SpikeFedora, terje.rosten
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-12-13 15:33:41 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: 1983926    
Attachments:
Description Flags
GCC Compilation error none

Description Michal Schorm 2021-08-04 08:12:45 UTC 
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.
Comment 1 Terje Røsten 2021-08-10 11:39:04 UTC 
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.
Comment 2 Ben Cotton 2021-08-10 13:34:29 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.
Comment 3 Lukas Javorsky 2021-08-12 07:37:04 UTC 
Link to commit fixing this issue: https://src.fedoraproject.org/rpms/community-mysql/c/e6208748d4cab839241ba89f69a1c3b6183a0b21?branch=rawhide
Comment 4 Michal Schorm 2021-08-12 08:55:47 UTC 
(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.
Comment 5 Ben Cotton 2022-11-29 17:02:56 UTC 
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.
Comment 6 Ben Cotton 2022-12-13 15:33:41 UTC 
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.