From Fedora Project Wiki
No edit summary
m (Fix two F34 typos that should be F36.)
 
(25 intermediate revisions by 4 users not shown)
Line 33: Line 33:
* Name: [[User:Codonell|Carlos O'Donell]]
* Name: [[User:Codonell|Carlos O'Donell]]
* Email: carlos@redhat.com
* Email: carlos@redhat.com
* Release notes owner: carlos@redhat.com
* Release notes ticket:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->


== Current status ==
== Current status ==
* Targeted release: [[Releases/29 | Fedora 29]]  
[[Category:ChangeAcceptedF36]]
* Last updated: 2018-06-19
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangePageIncomplete (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
<!-- Select proper category, default is Self Contained Change -->
<!-- [[Category:SelfContainedChange]] -->
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]
 
* Targeted release: [[Releases/36 | Fedora 36]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 48: Line 56:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug:
* FESCo issue: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1649936 #1649936]
* Release Notes tracker: <will be assigned by the Wrangler>


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
IBM has designed a new long double ABI that adheres to the 128-bit IEEE format. This format is more standard than the existing AIX double-double or IBM long double (2 grouped 64-bit doubles) which has discontinuous mantissas and is difficult for developers to use. In Fedora 29 the plan is to switch to the new ABI for long double, while still supporting old applications via compatibility symbols. Newly compiled applications use either the old or new ABI but not a mix of both. Changes are required in the core C libraries, and the compiler and the compiler runtimes including the C++ standard libraries. Therefore there is coordination required across the core toolchain componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).
IBM has designed a new long double ABI that adheres to the 128-bit IEEE format. This format is more standard than the existing AIX double-double or IBM long double (2 grouped 64-bit doubles) which has discontinuous mantissas and is difficult for developers to use. In Fedora 36 the plan is to switch to the new ABI for long double, while still supporting old applications via compatibility symbols. Newly compiled applications use either the old or new ABI but not a mix of both. Changes are required in the core C libraries, and the compiler and the compiler runtimes including the C++ standard libraries. Therefore there is coordination required across the core toolchain componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 60: Line 70:
== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the change in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the developers have to accomplish to complete the change in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
The change is relatively limited in that not many packages use the long double floating point ABI. The double floating point ABI is much more used, but not long double. It is estimated that few packages use long double directly, and those packages will need to be rebuilt in order to use the new ABI. This rebuilding can be targetted by analyzing which packages have long double usage in their debug information and rebuilding just those packages. However, we plan to just use the existing mass rebuild for glibc 2.28 to handle this issue.
The change is relatively limited in that not many packages use the long double floating point ABI. The double floating point ABI is much more used, but not long double. It is estimated that few packages use long double directly, and those packages will need to be rebuilt in order to use the new ABI. This rebuilding can be targeted by analyzing which packages have long double usage in their debug information and rebuilding just those packages. However, we plan to just use the existing mass rebuild for glibc 2.35 to handle this issue.


* Proposal owners: Transition glibc to float128 format for long double for IBM ppc64le. Transition gcc to the default for long double. Ensure gdb can handle the new types.
* Proposal owners: Transition glibc to float128 format for long double for IBM ppc64le. Transition gcc to the default for long double. Implement support for the new <code>long double</code> format in libstdc++. Ensure gdb can handle the new types.
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 29 branch.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 36 branch.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: A mass rebuild request has been filed for the parent system-wide change to upgrade glibc to 2.28<br>[https://pagure.io/releng/issue/7475 #7475]<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: A mass rebuild request has been filed for the parent system-wide change to upgrade glibc to 2.35<br>[https://pagure.io/releng/issue/9491 #9491]<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora29|List of deliverables]]: <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: The policies and guidelines do not need to be updated. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: The policies and guidelines do not need to be updated. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 79: Line 88:
== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
The library and language runtimes are backwards compatible with the version shipped in Fedora 28.
The library and language runtimes are backwards compatible with the version shipped in Fedora.


We fully expect to fix all packaging changes in Fedora Rawhide first when everything is ready.
We fully expect to fix all packaging changes in Fedora Rawhide first when everything is ready.
Line 117: Line 126:
== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: Given that Rawhide has started tracking glibc 2.28, no show-stopper problems are expected.  At this point, we can still revert to upstream version 2.27 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.
* Contingency mechanism: Ship without this feature if it is not ready. We would need to revert the default settings and do a mass rebuild to remove the ABI.


<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: Upstream ABI freeze deadline of 2018-08-01. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Final mass rebuild before Fedora release. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? Upgrading glibc does block the release. We should not ship without the float128 ABI change.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? Upgrading glibc does block the release. We should not ship without a decision being made for the float128 ABI change.<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


== Documentation ==
== Documentation ==
Line 136: Line 145:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
The GNU C Library version 2.28 will be released at the beginning of August 2018. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
* The ppc64le architecture changed the format of the <code>long double</code> type to binary128. (Previously, a pair of two doubles was used.)
 
[[Category:ChangeAnnounced]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangePageIncomplete (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
<!-- Select proper category, default is Self Contained Change -->
<!-- [[Category:SelfContainedChange]] -->
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]

Latest revision as of 03:51, 21 February 2022


New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

Summary

Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI.

Owner

Current status

  • Targeted release: Fedora 36
  • Last updated: 2022-02-21
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: #1649936
  • Release Notes tracker: <will be assigned by the Wrangler>

Detailed Description

IBM has designed a new long double ABI that adheres to the 128-bit IEEE format. This format is more standard than the existing AIX double-double or IBM long double (2 grouped 64-bit doubles) which has discontinuous mantissas and is difficult for developers to use. In Fedora 36 the plan is to switch to the new ABI for long double, while still supporting old applications via compatibility symbols. Newly compiled applications use either the old or new ABI but not a mix of both. Changes are required in the core C libraries, and the compiler and the compiler runtimes including the C++ standard libraries. Therefore there is coordination required across the core toolchain componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).

Benefit to Fedora

Fedora developers will be using a standard 128-bit IEEE format for long double instead of the non-standard double-double AIX format which has a discontinuous mantissa and multiple representations for the same value.

Scope

The change is relatively limited in that not many packages use the long double floating point ABI. The double floating point ABI is much more used, but not long double. It is estimated that few packages use long double directly, and those packages will need to be rebuilt in order to use the new ABI. This rebuilding can be targeted by analyzing which packages have long double usage in their debug information and rebuilding just those packages. However, we plan to just use the existing mass rebuild for glibc 2.35 to handle this issue.

  • Proposal owners: Transition glibc to float128 format for long double for IBM ppc64le. Transition gcc to the default for long double. Implement support for the new long double format in libstdc++. Ensure gdb can handle the new types.
  • Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 36 branch.
  • Release engineering: A mass rebuild request has been filed for the parent system-wide change to upgrade glibc to 2.35
    #9491
  • Policies and guidelines: The policies and guidelines do not need to be updated.
  • Trademark approval: Not needed for this change

Upgrade/compatibility impact

The library and language runtimes are backwards compatible with the version shipped in Fedora.

We fully expect to fix all packaging changes in Fedora Rawhide first when everything is ready.

How To Test

The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 2500+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones.

Specific testing for 128-bit IEEE long double ABI will be carried out by the glibc testsuite. Integration smoke testing will be carried out by the glibc developers to make sure new applications are built with the correct defaults and work as expected.

Specific testing for 128-bit IEEE long double ABI will be carried out by the gcc testsuite.

Specific smoke testing will be carried out using gdb to read and write the new types.

User Experience

Users will see a new 128-bit floating point ABI, but this will largely be transparent to them. On POWER hardware that supports 128-bit long double in hardware the compiler will use the hardware transparently to accelerate floating point operations, otherwise software floating point emulation will be used.

Dependencies

This change requires coordination of glibc and gcc to change the compiler defaults and build the compiler language runtimes correctly. Also gdb must be able to support the new type to make the process of transition seamless.

Contingency Plan

  • Contingency mechanism: Ship without this feature if it is not ready. We would need to revert the default settings and do a mass rebuild to remove the ABI.
  • Contingency deadline: Final mass rebuild before Fedora release.
  • Blocks release? Upgrading glibc does block the release. We should not ship without a decision being made for the float128 ABI change.

Documentation

The glibc/gcc manual contain the documentation for the release and don't need any more additional work.

Release Notes

  • The ppc64le architecture changed the format of the long double type to binary128. (Previously, a pair of two doubles was used.)