From Fedora Project Wiki
< Changes
(→Benefit to Fedora: "delete" one sentence) |
|||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 23: | Line 23: | ||
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: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1397147 #1397147] | ||
== Detailed Description == | == Detailed Description == | ||
| Line 30: | Line 30: | ||
* Drop <code>-mtune=atom</code> on i686: This flag was added to improve performance on the Intel Bonnell microarchitecture. Such CPUs are rare these days. In addition, many users of the i686 packages download them for use within a 64-bit x86_64 installation, and only a small part of these Fedora installations use Atom CPUs. Current microarchitectures for Atom CPUs are different from the original Bonnell microarchtecture and would need different GCC flags for tuning, but many current Atom-based devices cannot run Fedora because Fedora does not support their 32-bit UEFI boot environment. | * Drop <code>-mtune=atom</code> on i686: This flag was added to improve performance on the Intel Bonnell microarchitecture. Such CPUs are rare these days. In addition, many users of the i686 packages download them for use within a 64-bit x86_64 installation, and only a small part of these Fedora installations use Atom CPUs. Current microarchitectures for Atom CPUs are different from the original Bonnell microarchtecture and would need different GCC flags for tuning, but many current Atom-based devices cannot run Fedora because Fedora does not support their 32-bit UEFI boot environment. | ||
* Add <code>-Werror=implicit-function-declaration</code>: Implicit function declarations allows a programmer to call functions without declaring them (or including the relevant header files). The official C language specification has not supported implicit function declarations for almost two decades now. GCC still supports them as a GNU extension. Implicit function declarations introduce bugs because these functions use a different calling convention and have a fixed return type of <code>int</code>. Resulting issues are pointer truncation (on 64-bit architectures), exposure of padding bits (particular for <code>bool</code>-returning functions on x86_64), and unexpected lack of hardening. Implicit function declarations are not part of C++ (with or without GNU extensions), and adjusting C code accordingly simplifies reuse in C++ projects. | * <strike>Add <code>-Werror=implicit-function-declaration</code>: Implicit function declarations allows a programmer to call functions without declaring them (or including the relevant header files). The official C language specification has not supported implicit function declarations for almost two decades now. GCC still supports them as a GNU extension. Implicit function declarations introduce bugs because these functions use a different calling convention and have a fixed return type of <code>int</code>. Resulting issues are pointer truncation (on 64-bit architectures), exposure of padding bits (particular for <code>bool</code>-returning functions on x86_64), and unexpected lack of hardening. Implicit function declarations are not part of C++ (with or without GNU extensions), and adjusting C code accordingly simplifies reuse in C++ projects.</strike> | ||
* Add <code>-Werror=implicit-int</code>: Implicit <code>int</code>s were removed from the C programming language at the same time as implicit function definitions, and were also retained as a GNU extension. Implicit <code>int</code>s are usually source code bugs, and the presence of such code may interfere with future C language directions (for example, consider how C++ reused the <code>auto</code> keyword and an omitted type specifier). | * <strike>Add <code>-Werror=implicit-int</code>: Implicit <code>int</code>s were removed from the C programming language at the same time as implicit function definitions, and were also retained as a GNU extension. Implicit <code>int</code>s are usually source code bugs, and the presence of such code may interfere with future C language directions (for example, consider how C++ reused the <code>auto</code> keyword and an omitted type specifier).</strike> | ||
The main risk from these changes are incorrect autoconf feature checks, which often rely on technically invalid C fragments. However, a review of existing configure scripts did not find any places where they relied on these two problematic GNU extensions. | <strike>The main risk from these changes are incorrect autoconf feature checks, which often rely on technically invalid C fragments. However, a review of existing configure scripts did not find any places where they relied on these two problematic GNU extensions.</strike> | ||
The technical side of this change is tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=1393492 bug 1393492]. | The technical side of this change is tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=1393492 bug 1393492]. | ||
| Line 39: | Line 39: | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
i686 binaries will run a little faster on current hardware. | i686 binaries will run a little faster on current hardware. <strike>C code will be prepared for future C language updates, and can be used more easily in C++ programs.</strike> | ||
== Scope == | == Scope == | ||
| Line 59: | Line 59: | ||
== How To Test == | == How To Test == | ||
Regular regression testing covers this. Program behavior will not change as long as the programs still | Regular regression testing covers this. Program behavior will not change as long as the programs still compile. | ||
== User Experience == | == User Experience == | ||
| Line 79: | Line 79: | ||
== Release Notes == | == Release Notes == | ||
This change does not seem to | This change does not seem to meet the threshold for the release notes. It is only about internal housekeeping. | ||
[[Category: | [[Category:ChangeAcceptedF26]] | ||
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> | <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (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--> | <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--> | ||
<!-- Hey, here is an edit/change. Did it generate watch list emails? --> | |||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
Latest revision as of 17:18, 31 January 2017
Fedora 26 C/C++ Compilation Flags Updates
Summary
This change updates the default C/C++ compilation flags, as determined by the redhat-rpm-config package.
Owner
- Name: Florian Weimer
- Email: [1]
- Release notes owner:
Current status
Detailed Description
This change covers the following modifications to the default C and C++ compiler flags in the redhat-rpm-config package.
- Drop
-mtune=atomon i686: This flag was added to improve performance on the Intel Bonnell microarchitecture. Such CPUs are rare these days. In addition, many users of the i686 packages download them for use within a 64-bit x86_64 installation, and only a small part of these Fedora installations use Atom CPUs. Current microarchitectures for Atom CPUs are different from the original Bonnell microarchtecture and would need different GCC flags for tuning, but many current Atom-based devices cannot run Fedora because Fedora does not support their 32-bit UEFI boot environment. Add-Werror=implicit-function-declaration: Implicit function declarations allows a programmer to call functions without declaring them (or including the relevant header files). The official C language specification has not supported implicit function declarations for almost two decades now. GCC still supports them as a GNU extension. Implicit function declarations introduce bugs because these functions use a different calling convention and have a fixed return type ofint. Resulting issues are pointer truncation (on 64-bit architectures), exposure of padding bits (particular forbool-returning functions on x86_64), and unexpected lack of hardening. Implicit function declarations are not part of C++ (with or without GNU extensions), and adjusting C code accordingly simplifies reuse in C++ projects.Add-Werror=implicit-int: Implicitints were removed from the C programming language at the same time as implicit function definitions, and were also retained as a GNU extension. Implicitints are usually source code bugs, and the presence of such code may interfere with future C language directions (for example, consider how C++ reused theautokeyword and an omitted type specifier).
The main risk from these changes are incorrect autoconf feature checks, which often rely on technically invalid C fragments. However, a review of existing configure scripts did not find any places where they relied on these two problematic GNU extensions.
The technical side of this change is tracked in bug 1393492.
Benefit to Fedora
i686 binaries will run a little faster on current hardware. C code will be prepared for future C language updates, and can be used more easily in C++ programs.
Scope
- Proposal owners: The defaults in
redhat-rpm-configneed to be changed, as described above.
- Other developers: Source code which relies on implicit function declarations or implicit
ints needs to be adjusted.
- Release engineering: This change requires a mass rebuild to become fully effective.
- List of deliverables: No release blocking deliverables.
- Policies and guidelines: no changes proposed (change will be implemented through
redhat-rpm-config)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
There will be no impact.
How To Test
Regular regression testing covers this. Program behavior will not change as long as the programs still compile.
User Experience
There will be no user-visible impact.
Dependencies
The redhat-rpm-config change should be made as soon as possible, well before the first mass rebuild.
Contingency Plan
- Contingency mechanism: Drop the change.
- Contingency deadline: Final mass rebuild.
- Blocks release? No.
- Blocks product? No.
Documentation
No documentation updates are needed.
Release Notes
This change does not seem to meet the threshold for the release notes. It is only about internal housekeeping.