https://fedoraproject.org/w/api.php?action=feedcontributions&user=Jakub&feedformat=atomFedoraProject - User contributions [en]2016-12-09T16:12:51ZUser contributionsMediaWiki 1.19.24https://fedoraproject.org/wiki/Changes/GCC6Changes/GCC62015-12-22T11:32:26Z<p>Jakub: Created page with &quot;= GCC6 &lt;!-- The name of your change proposal --&gt; = == Summary == Switch GCC in Fedora 24 to 6.x.y, rebuild all packages with it, or optionally rebuild just some packages with...&quot;</p>
<hr />
<div>= GCC6 &lt;!-- The name of your change proposal --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 24 to 6.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 25.<br />
<br />
== Owner ==<br />
* Name: [[User:jakub| Jakub Jelínek]]<br />
* Email: jakub@redhat.com<br />
* Release notes owner: &lt;!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] &lt;email address&gt; --&gt;<br />
&lt;!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] &lt;email address&gt;<br />
--&gt;<br />
&lt;!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env &amp; Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/24 | Fedora 24 ]] <br />
* Last updated: 2015-12-22<br />
&lt;!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -&gt; change proposal is submitted and announced<br />
ASSIGNED -&gt; accepted by FESCo with on going development<br />
MODIFIED -&gt; change is substantially done and testable<br />
ON_QA -&gt; change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -&gt; change is completed and verified and will be delivered in next release under development<br />
--&gt;<br />
* Tracker bug: &lt;will be assigned by the Wrangler&gt;<br />
<br />
== Detailed Description ==<br />
GCC 6 is currently in stage3, will move to stage4 around mid January, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April.<br />
We are working on scratch gcc rpms and will perform a test mass rebuild.<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-6/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f24, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots.<br />
<br />
* Proposal owners:<br />
Build gcc in f24, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin, odb).<br />
<br />
* Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-6/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.<br />
<br />
* Release engineering: Organize a mass rebuild, either in f24 or in f25<br />
<br />
* Policies and guidelines: No policies need to be changed &lt;!-- REQUIRED FOR SYSTEM WIDE CHANGES --&gt;<br />
&lt;!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --&gt;<br />
<br />
== Upgrade/compatibility impact ==<br />
No impact<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features.<br />
Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-6/porting_to.html, or, if they detect a GCC bug, report it.<br />
<br />
== Dependencies ==<br />
libtool, gcc-python-plugin, odb, llvm depend on exact gcc version, those need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
* Contingency mechanism: Revert to older gcc, mass rebuild everything again<br />
* Contingency deadline: Before release<br />
* Blocks release? Yes<br />
* Blocks product? No<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-6/<br />
<br />
== Release Notes ==<br />
Fedora 24 comes with GCC 6.1 as primary compiler, see http://gcc.gnu.org/gcc-6/changes.html for user visible changes in it.<br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
[[Category:SystemWideChange]]</div>Jakubhttps://fedoraproject.org/wiki/Changes/GCC5Changes/GCC52015-01-19T16:30:12Z<p>Jakub: </p>
<hr />
<div>= GCC5 &lt;!-- The name of your change proposal --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 22 to 5.x.y, rebuild some packages with it. <br />
<br />
== Owner ==<br />
* Name: [[User:jakub| Jakub Jelínek]]<br />
* Email: jakub@redhat.com<br />
* Release notes owner: &lt;!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] &lt;email address&gt; --&gt;<br />
&lt;!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] &lt;email address&gt;<br />
--&gt;<br />
&lt;!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env &amp; Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/22 | Fedora 22 ]] <br />
* Last updated: 2015-01-19<br />
&lt;!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -&gt; change proposal is submitted and announced<br />
ASSIGNED -&gt; accepted by FESCo with on going development<br />
MODIFIED -&gt; change is substantially done and testable<br />
ON_QA -&gt; change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -&gt; change is completed and verified and will be delivered in next release under development<br />
--&gt;<br />
* Tracker bug: &lt;will be assigned by the Wrangler&gt;<br />
<br />
== Detailed Description ==<br />
GCC 5 is currently in stage4 - prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April.<br />
Scratch rpms are at http://koji.fedoraproject.org/scratch/jakub/task_8642235/ and test mass rebuild is in progress.<br />
Other distributions have performed test mass rebuilds already.<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-5/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
GCC 5.x.y will be added to Fedora 22, afterwards packages that will be rebuilt for other reasons will be built using GCC 5.<br />
<br />
* Proposal owners:<br />
Build gcc in f22, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).<br />
<br />
* Other developers: Just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.<br />
<br />
* Release engineering: Nothing, mass rebuild of F22 has been denied by FESCO.<br />
<br />
* Policies and guidelines: No policies need to be changed &lt;!-- REQUIRED FOR SYSTEM WIDE CHANGES --&gt;<br />
&lt;!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --&gt;<br />
<br />
== Upgrade/compatibility impact ==<br />
No impact<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and added partial C++14 support, OpenMP 4.0 offloading support and OpenACC 2.0 support, improved vectorization support, etc.<br />
Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-5/porting_to.html, or, if they detect a GCC bug, report it.<br />
<br />
== Dependencies ==<br />
libtool, dragonegg, gcc-python-plugin, llvm depend on exact gcc version, those need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
worst case we rebuild some or all packages that have been built with the newer gcc if we'd need to revert to older gcc.<br />
<br />
* Contingency mechanism: Revert to older gcc, rebuild what needs to be rebuilt again<br />
* Contingency deadline: Before release<br />
* Blocks release? Yes<br />
* Blocks product? No<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-5/<br />
<br />
== Release Notes ==<br />
Fedora 22 comes with GCC 5.1 as primary compiler, see http://gcc.gnu.org/gcc-5/changes.html for user visible changes in it.<br />
<br />
[[Category:ChangeAnnounced]]<br />
[[Category:SystemWideChange]]</div>Jakubhttps://fedoraproject.org/wiki/Changes/GCC5Changes/GCC52015-01-14T09:51:29Z<p>Jakub: Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.</p>
<hr />
<div>= GCC5 &lt;!-- The name of your change proposal --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: [[User:jakub| Jakub Jelínek]]<br />
* Email: jakub@redhat.com<br />
* Release notes owner: &lt;!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] &lt;email address&gt; --&gt;<br />
&lt;!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] &lt;email address&gt;<br />
--&gt;<br />
&lt;!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env &amp; Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/22 | Fedora 22 ]] <br />
* Last updated: 2015-01-14<br />
&lt;!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -&gt; change proposal is submitted and announced<br />
ASSIGNED -&gt; accepted by FESCo with on going development<br />
MODIFIED -&gt; change is substantially done and testable<br />
ON_QA -&gt; change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -&gt; change is completed and verified and will be delivered in next release under development<br />
--&gt;<br />
* Tracker bug: &lt;will be assigned by the Wrangler&gt;<br />
<br />
== Detailed Description ==<br />
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April.<br />
We are working on scratch gcc rpms and will perform a test mass rebuild.<br />
Other distributions have performed test mass rebuilds already.<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-5/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f22.<br />
<br />
* Proposal owners:<br />
Build gcc in f22, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).<br />
<br />
* Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.<br />
<br />
* Release engineering: Organize a mass rebuild<br />
<br />
* Policies and guidelines: No policies need to be changed &lt;!-- REQUIRED FOR SYSTEM WIDE CHANGES --&gt;<br />
&lt;!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --&gt;<br />
<br />
== Upgrade/compatibility impact ==<br />
No impact<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and added partial C++14 support, OpenMP 4.0 offloading support and OpenACC 2.0 support, improved vectorization support, etc.<br />
Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-5/porting_to.html, or, if they detect a GCC bug, report it.<br />
<br />
== Dependencies ==<br />
libtool, dragonegg, gcc-python-plugin, llvm depend on exact gcc version, those need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
* Contingency mechanism: Revert to older gcc, mass rebuild everything again<br />
* Contingency deadline: Before release<br />
* Blocks release? Yes<br />
* Blocks product? No<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-5/<br />
<br />
== Release Notes ==<br />
Fedora 22 comes with GCC 5.1 as primary compiler, see http://gcc.gnu.org/gcc-5/changes.html for user visible changes in it.<br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
[[Category:SystemWideChange]]</div>Jakubhttps://fedoraproject.org/wiki/Changes/GCC49Changes/GCC492014-03-28T17:14:29Z<p>Jakub: Created page with &quot;= Change Proposal GCC49 &lt;!-- The name of your change proposal --&gt; = == Summary == Switch GCC in Fedora 21 to 4.9.x, rebuild all packages with it. == Owner == * Name: [[User...&quot;</p>
<hr />
<div>= Change Proposal GCC49 &lt;!-- The name of your change proposal --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 21 to 4.9.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: [[User:jakub| Jakub Jelínek]]<br />
* Email: jakub@redhat.com<br />
* Release notes owner: &lt;!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] &lt;email address&gt; --&gt;<br />
&lt;!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] &lt;email address&gt;<br />
--&gt;<br />
&lt;!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env &amp; Stacks)<br />
* Product:<br />
* Responsible WG:<br />
--&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/21 | Fedora 21 ]] <br />
* Last updated: 2014-03-28<br />
&lt;!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -&gt; change proposal is submitted and announced<br />
ASSIGNED -&gt; accepted by FESCo with on going development<br />
MODIFIED -&gt; change is substantially done and testable<br />
ON_QA -&gt; change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -&gt; change is completed and verified and will be delivered in next release under development<br />
--&gt;<br />
* Tracker bug: &lt;will be assigned by the Wrangler&gt;<br />
<br />
== Detailed Description ==<br />
GCC 4.9.0 is currently in stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April.<br />
Marek Polacek has performed a test mass rebuild on x86_64 with gcc-4.9.0-0.*.fc21, most packages have built successfully, others have failed to rebuild also with gcc 4.8.x, for the remaining packages<br />
most of the needed changes are now tracked in http://gcc.gnu.org/gcc-4.9/porting_to.html or, if it were bugs on the gcc side, have been fixed in the mean time.<br />
GCC 4.9.0 prereleases have so far been built as scratch packages, http://koji.fedoraproject.org/scratch/jakub/task_6667028/ (and similarly for ppc* and s390* secondary architectures).<br />
Other distributions have performed test mass rebuilds on other architectures (i?86, s390x, arm).<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.9/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f21.<br />
<br />
* Proposal owners:<br />
Build gcc in f21, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).<br />
<br />
* Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-4.9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.<br />
<br />
* Release engineering: Organize a mass rebuild<br />
<br />
* Policies and guidelines: No policies need to be changed &lt;!-- REQUIRED FOR SYSTEM WIDE CHANGES --&gt;<br />
&lt;!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --&gt;<br />
<br />
== Upgrade/compatibility impact ==<br />
No impact<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and added partial C++14 support, OpenMP 4.0 support, improved vectorization support, etc.<br />
Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-4.9/porting_to.html, or, if they detect a GCC bug, report it.<br />
<br />
== Dependencies ==<br />
libtool, dragonegg, gcc-python-plugin, llvm depend on exact gcc version, those need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
* Contingency mechanism: Revert to older gcc, mass rebuild everything again<br />
* Contingency deadline: Before release<br />
* Blocks release? No<br />
* Blocks product? No<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.9/<br />
<br />
== Release Notes ==<br />
Fedora 21 comes with GCC 4.9.0 as primary compiler, see http://gcc.gnu.org/gcc-4.9/changes.html for user visible changes in it.<br />
<br />
[[Category:ChangeReadyForWrangler]]<br />
[[Category:SystemWideChange]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC48Features/GCC482013-05-15T05:48:49Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= GCC 4.8.x =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19]]<br />
* Last updated: 2013-05-15<br />
* Percentage of completion: 100%<br />
<br />
== Detailed Description ==<br />
GCC 4.8.0 has been released on March, 22nd and is currently in regression bugfix only mode. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933 packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19 (thus unlikely gcc related),<br />
67 packages failed due to issues on the side of the packages, 22 failed due to bugs on the gcc side that should be fixed already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed on the GCC side.<br />
See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details.<br />
After gcc-4.8.0-* has been built into Fedora, a mass rebuild has been performed.<br />
GCC 4.8.1 is going to be released in a week or so.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.8/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f19.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.8/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 19 comes with GCC 4.8.0 as primary compiler, see http://gcc.gnu.org/gcc-4.8/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC48]]<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC48Features/GCC482013-03-18T13:11:52Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= GCC 4.8.x =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19]]<br />
* Last updated: 2013-03-18<br />
* Percentage of completion: 95%<br />
<br />
== Detailed Description ==<br />
GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933 packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19 (thus unlikely gcc related),<br />
67 packages failed due to issues on the side of the packages, 22 failed due to bugs on the gcc side that should be fixed already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed on the GCC side.<br />
See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details.<br />
Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed.<br />
Mass rebuild with gcc 4.8.0 prereleases has been performed, reported bugs fixed and GCC 4.8.0 is going to be released really soon now.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.8/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f19.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.8/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 19 comes with GCC 4.8.0 as primary compiler, see http://gcc.gnu.org/gcc-4.8/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC48]]<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC48Features/GCC482013-01-16T17:30:14Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= GCC 4.8.x =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19]]<br />
* Last updated: 2013-01-08<br />
* Percentage of completion: 50%<br />
<br />
== Detailed Description ==<br />
GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933 packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19 (thus unlikely gcc related),<br />
67 packages failed due to issues on the side of the packages, 22 failed due to bugs on the gcc side that should be fixed already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed on the GCC side.<br />
See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details.<br />
Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.8/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f19.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past,<br />
but worst case we can mass rebuild everything with older gcc again.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.8/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 19 comes with GCC 4.8.0 as primary compiler, see http://gcc.gnu.org/gcc-4.8/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC48]]<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC48Features/GCC482013-01-08T16:03:36Z<p>Jakub: Created page with &quot;&lt;!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. ...&quot;</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= GCC 4.8.x =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19]]<br />
* Last updated: 2013-01-08<br />
* Percentage of completion: 50%<br />
<br />
== Detailed Description ==<br />
GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933 packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19 (thus unlikely gcc related),<br />
67 packages failed due to issues on the side of the packages, 22 failed due to bugs on the gcc side that should be fixed already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed on the GCC side.<br />
See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.8/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits f19.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.8/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 19 comes with GCC 4.8.0 as primary compiler, see http://gcc.gnu.org/gcc-4.8/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC48]]<br />
<br />
<br />
[[Category:ReadyForWrangler]]</div>Jakubhttps://fedoraproject.org/wiki/Features/DwarfCompressorFeatures/DwarfCompressor2012-07-18T11:20:05Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= DWARF Compressior =<br />
<br />
== Summary ==<br />
Reduce size of *.debug files in debuginfo packages in Fedora 18 using DWARF Compressor dwz.<br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18]]<br />
* Last updated: 2012-07-18<br />
* Percentage of completion: 100%<br />
<br />
== Detailed Description ==<br />
The dwz tool http://sourceware.org/git/?p=dwz.git;a=summary can rewrite .debug_* sections, either in binaries/shared libraries, or their *.debug split files, into equivalent, but smaller,<br />
DWARF. The tool with -m option also attempts to optimize also several *.debug files at once, by moving common .debug_* data into a single new ET_REL *.debug file and using DWARF<br />
extensions refer to that from the *.debug files. The rpm and redhat-rpm-config packages have been tweaked to invoke this tool by default during find-debuginfo.sh.<br />
<br />
== Benefit to Fedora ==<br />
Smaller debuginfo files.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new tool as well as rpm changes hit dist-f18.<br />
<br />
== How To Test ==<br />
GDB testsuite, perhaps some tool to analyze whether the non-compressed and compressed debuginfos contain equivalent info.<br />
<br />
== User Experience ==<br />
Users shouldn't notice this, except that debuginfo files will be smaller, and newer DWARF consumers will be needed (gdb, valgrind, dwarves, prelink, elfutils, systemtap).<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
Worst case we stop using the compressor.<br />
<br />
== Documentation ==<br />
http://www.dwarfstd.org/ShowIssue.php?issue=120604.1&amp;type=open and dwz manual page.<br />
<br />
== Release Notes ==<br />
Fedora 18 debuginfo has been post-processed by a DWARF compressor tool to reduce size of the *.debug files.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/DwarfCompressor]]<br />
<br />
<br />
[[Category:FeatureAcceptedF18]]</div>Jakubhttps://fedoraproject.org/wiki/Features/DwarfCompressorFeatures/DwarfCompressor2012-06-05T13:16:28Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= DWARF Compressior =<br />
<br />
== Summary ==<br />
Reduce size of *.debug files in debuginfo packages in Fedora 18 using DWARF Compressor dwz.<br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18]]<br />
* Last updated: 2012-06-05<br />
* Percentage of completion: 50%<br />
<br />
== Detailed Description ==<br />
The dwz tool http://sourceware.org/git/?p=dwz.git;a=summary can rewrite .debug_* sections, either in binaries/shared libraries, or their *.debug split files, into equivalent, but smaller,<br />
DWARF. The master branch of that repo currently only rewrites each single *.debug file on its own, on the multifile branch there is ongoing work to optimize also several *.debug files<br />
at once, by moving common .debug_* data into a single new ET_REL *.debug file and using DWARF extensions refer to that from the *.debug files.<br />
Depending on the stability of the multifile branch we'd like to either optimize each *.debug file individually by running roughly find . -name \*.debug | xargs -n 1 dwz<br />
in find-debuginfo.sh (will need to handle hardlinks better than that), or all *.debug files at once using dwz -m %{name}-%{version}-%{release}.%{arch}.debug *.debug.<br />
<br />
== Benefit to Fedora ==<br />
Smaller debuginfo files.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new tool as well as rpm changes hit dist-f18.<br />
<br />
== How To Test ==<br />
GDB testsuite, perhaps some tool to analyze whether the non-compressed and compressed debuginfos contain equivalent info.<br />
<br />
== User Experience ==<br />
Users shouldn't notice this, except that debuginfo files will be smaller, and newer DWARF consumers will be needed (gdb, valgrind, dwarves, prelink, elfutils, systemtap).<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
Worst case we stop using the compressor.<br />
<br />
== Documentation ==<br />
None yet, there will be a DWARF5 extension proposal if we are going to choose the multifile optimization.<br />
<br />
== Release Notes ==<br />
Fedora 18 debuginfo has been post-processed by a DWARF compressor tool to reduce size of the *.debug files.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/DwarfCompressor]]<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]</div>Jakubhttps://fedoraproject.org/wiki/Features/DwarfCompressorFeatures/DwarfCompressor2012-05-11T13:59:31Z<p>Jakub: Created page with &quot;&lt;!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. --...&quot;</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= DWARF Compressior =<br />
<br />
== Summary ==<br />
Reduce size of *.debug files in debuginfo packages in Fedora 18 using DWARF Compressor dwz.<br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18]]<br />
* Last updated: 2012-05-11<br />
* Percentage of completion: 30%<br />
<br />
== Detailed Description ==<br />
The dwz tool http://sourceware.org/git/?p=dwz.git;a=summary can rewrite .debug_* sections, either in binaries/shared libraries, or their *.debug split files, into equivalent, but smaller,<br />
DWARF. The master branch of that repo currently only rewrites each single *.debug file on its own, on the multifile branch there is ongoing work to optimize also several *.debug files<br />
at once, by moving common .debug_* data into a single new ET_REL *.debug file and using DWARF extensions refer to that from the *.debug files.<br />
Depending on the stability of the multifile branch we'd like to either optimize each *.debug file individually by running roughly find . -name \*.debug | xargs -n 1 dwz<br />
in find-debuginfo.sh (will need to handle hardlinks better than that), or all *.debug files at once using dwz -m %{name}-%{version}-%{release}.%{arch}.debug *.debug.<br />
<br />
== Benefit to Fedora ==<br />
Smaller debuginfo files.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new tool as well as rpm changes hit dist-f18.<br />
<br />
== How To Test ==<br />
GDB testsuite, perhaps some tool to analyze whether the non-compressed and compressed debuginfos contain equivalent info.<br />
<br />
== User Experience ==<br />
Users shouldn't notice this, except that debuginfo files will be smaller, and newer DWARF consumers will be needed (gdb, valgrind, dwarves, prelink, elfutils, systemtap).<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
Worst case we stop using the compressor.<br />
<br />
== Documentation ==<br />
None yet, there will be a DWARF5 extension proposal if we are going to choose the multifile optimization.<br />
<br />
== Release Notes ==<br />
Fedora 18 debuginfo has been post-processed by a DWARF compressor tool to reduce size of the *.debug files.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/DwarfCompressor]]<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC47Features/GCC472012-02-13T19:06:11Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= GCC 4.7.x =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 17 to 4.7.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/17]]<br />
* Last updated: 2012-02-13<br />
* Percentage of completion: 95%<br />
<br />
== Detailed Description ==<br />
GCC 4.7.0 is going to be released in mid March to mid April, is currently in bugfix only mode and is going to switch into regression bug fix mode in January. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.7.0-0.1.fc17, out of 11270 packages 10056 built successfully, 845 packages failed to build both with gcc-4.7.0-0.1.fc17 and gcc-4.6.2-1.fc16 (thus unlikely gcc related),<br />
108 failed to build due to missing &lt;unistd.h&gt; includes (which is no longer incorrectly included as implementation detail of some STL headers), 60 + 28 packages failed to build due to fixes in C++ lookup,<br />
23 failed because boost needs fixing for gcc 4.7.0. I've encountered 3 different ICEs during the mass rebuild, all of them filed right now in upstream bugzilla.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.7/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f17.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
11000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.7/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 17 comes with GCC 4.7.0 as primary compiler, see http://gcc.gnu.org/gcc-4.7/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC47]]<br />
<br />
<br />
[[Category:FeatureAcceptedF17]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC47Features/GCC472011-12-30T19:25:12Z<p>Jakub: Created page with &quot;&lt;!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. --...&quot;</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= Feature Name &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 17 to 4.7.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/17]]<br />
* Last updated: (DATE)<br />
* Percentage of completion: 50%<br />
<br />
== Detailed Description ==<br />
GCC 4.7.0 is going to be released in mid March to mid April, is currently in bugfix only mode and is going to switch into regression bug fix mode in January. I've performed a test mass rebuild<br />
on x86_64 with gcc-4.7.0-0.1.fc17, out of 11270 packages 10056 built successfully, 845 packages failed to build both with gcc-4.7.0-0.1.fc17 and gcc-4.6.2-1.fc16 (thus unlikely gcc related),<br />
108 failed to build due to missing &lt;unistd.h&gt; includes (which is no longer incorrectly included as implementation detail of some STL headers), 60 + 28 packages failed to build due to fixes in C++ lookup,<br />
23 failed because boost needs fixing for gcc 4.7.0. I've encountered 3 different ICEs during the mass rebuild, all of them filed right now in upstream bugzilla.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.7/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f17.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and C11 support, improved vectorization support, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
11000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.7/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 17 comes with GCC 4.7.0 as primary compiler, see http://gcc.gnu.org/gcc-4.7/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC47]]<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC46Features/GCC462011-04-15T11:04:25Z<p>Jakub: </p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= Feature Name &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 15 to 4.6.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
* Name: Jakub Jelinek<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/15]]<br />
* Last updated: (DATE)<br />
* Percentage of completion: 100%<br />
<br />
== Detailed Description ==<br />
GCC 4.6.0 has been released on 2011-03-25. Fedora 15 has been rebuilt with it.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.6/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f15.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++0x support, support for the Go language, REAL*16 support in Fortran, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
8000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.6/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 15 comes with GCC 4.6.0 as primary compiler, see http://gcc.gnu.org/gcc-4.6/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC46]]<br />
<br />
<br />
[[Category:FeatureAcceptedF15]]</div>Jakubhttps://fedoraproject.org/wiki/Features/GCC46Features/GCC462010-12-13T16:29:40Z<p>Jakub: Created page with '&lt;!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. --...'</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= Feature Name &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 15 to 4.6.x, rebuild all packages with it. <br />
<br />
== Owner ==<br />
Name: Jakub Jelinek<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/15]]<br />
* Last updated: (DATE)<br />
* Percentage of completion: 50%<br />
<br />
== Detailed Description ==<br />
GCC 4.6.0 is going to be released in early to mid April, is currently in bugfix only mode and is going to switch into regression bug fix mode at start of January. AFAIK SUSE has done some preliminary<br />
mass package rebuild testing already, we'd perform it either during the Christmas break or shortly afterwards.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.6/changes.html for the list of changes.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f15.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++0x support, support for the Go language, REAL*16 support in Fortran, etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
8000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.6/changes.html<br />
<br />
== Release Notes ==<br />
Fedora 15 comes with GCC 4.6.0 as primary compiler, see http://gcc.gnu.org/gcc-4.6/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/GCC46]]<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]</div>Jakubhttps://fedoraproject.org/wiki/Features/gcc4.4Features/gcc4.42009-04-27T18:56:43Z<p>Jakub: </p>
<hr />
<div>= gcc 4.4 =<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 11 to 4.4.x, rebuild all packages with it.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: Jakub Jelinek<br />
* email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/11]]<br />
* Last updated: 2009-04-17<br />
* Percentage of completion: 100%<br />
<br />
== Detailed Description ==<br />
GCC 4.4.0 has been released on April, 21st and is included in dist-f11. Almost all packages have been rebuilt.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.4/changes.html for the list of changes. It features a new, rewritten, register allocator and a bunch of other improvements.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f11.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++0x support etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
8000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.4/changes.html<br />
<br />
<br />
== Release Notes ==<br />
Fedora 11 comes with GCC 4.4.0 as primary compiler, see http://gcc.gnu.org/gcc-4.4/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
<br />
* See [[Talk:Features/gcc4.4]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
----<br />
<br />
[[Category:FeatureAcceptedF11]]<br />
<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Jakubhttps://fedoraproject.org/wiki/Features/gcc4.4Features/gcc4.42009-01-26T20:53:22Z<p>Jakub: New page: {{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choo...</p>
<hr />
<div>{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible<br />
when viewing this page. To read it, choose the &quot;edit&quot; link.&lt;br/&gt; '''Copy the source to a ''new page'' before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''}}<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/YourFeatureName. This keeps all features in the same namespace --&gt;<br />
<br />
= Feature Name =<br />
Features/gcc4.4<br />
<br />
== Summary ==<br />
Switch GCC in Fedora 11 to 4.4.x, rebuild all packages with it.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[Jakub]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* email: jakub@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/11]]<br />
* Last updated: (DATE)<br />
* Percentage of completion: 70%<br />
<br />
== Detailed Description ==<br />
GCC 4.4.0 is going to be released soon (has been frozen for regression/documentation bugfixes only since November, 1st). Initial packages are prepared in dist-f11-gcc44.<br />
I'd also like to change default ISA and tuning flags for several architectures, -march=i586 -mtune=generic from -march=i386 -mtune=generic for i?86, -march=z9-109 -mtune=z10<br />
for s390{,x} and -march=power4 for powerpc -m64.<br />
<br />
== Benefit to Fedora ==<br />
See http://gcc.gnu.org/gcc-4.4/changes.html for the list of changes. It features a new, rewritten, register allocator and a bunch of other improvements.<br />
<br />
== Scope ==<br />
All packages should be rebuilt with the new gcc once it hits dist-f11.<br />
<br />
== How To Test ==<br />
GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.<br />
<br />
== User Experience ==<br />
Users will be able to see compiled code improvements and use the newly added features, such as improved C++0x support etc.<br />
<br />
== Dependencies ==<br />
All packages need to be rebuilt.<br />
<br />
== Contingency Plan ==<br />
If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in<br />
8000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc.<br />
<br />
== Documentation ==<br />
http://gcc.gnu.org/gcc-4.4/changes.html<br />
<br />
<br />
== Release Notes ==<br />
Fedora 11 comes with GCC 4.4.0 as primary compiler, see http://gcc.gnu.org/gcc-4.4/changes.html for user visible changes in it.<br />
<br />
== Comments and Discussion ==<br />
<br />
* See [[Talk:Features/YourFeatureName]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
----<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Jakub