[This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo]
https://fedoraproject.org/wiki/Changes/GCC9
== Summary == Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 31.
== Owner == * Name: [[User:jakub| Jakub Jelínek]] * Email: jakub@redhat.com
== Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide.
== Benefit to Fedora == See http://gcc.gnu.org/gcc-9/changes.html for the list of changes.
== Scope == All packages should be rebuilt with the new gcc once it hits f30, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots.
* Proposal owners: Build gcc in f30, rebuild packages that have direct dependencies on exact gcc version (libtool, annobin, gcc-python-plugin). * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. * Release engineering: . Mass rebuild requested for F30. * Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact == No impact
== How To Test == 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.
== User Experience == Users will be able to see compiled code improvements and use the newly added features. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, or, if they detect a GCC bug, report it.
== Dependencies == libtool, annobin, gcc-python-plugin depend on exact gcc version, those need to be rebuilt.
== Contingency Plan == 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 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, but worst case we can mass rebuild everything with older gcc again. Jeff Law has performed test mass rebuild on x86_64.
* Contingency mechanism: Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No
== Documentation == http://gcc.gnu.org/gcc-9/
== Release Notes == Fedora 30 comes with GCC 9.1 as primary compiler, see http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it.
On Mon, Jan 21, 2019 at 3:17 PM Ben Cotton bcotton@redhat.com wrote:
[This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo]
https://fedoraproject.org/wiki/Changes/GCC9
== Summary == Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 31.
== Owner ==
- Name: [[User:jakub| Jakub Jelínek]]
- Email: jakub@redhat.com
== Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide.
== Benefit to Fedora == See http://gcc.gnu.org/gcc-9/changes.html for the list of changes.
== Scope == All packages should be rebuilt with the new gcc once it hits f30, or, if there is not enough time for that, just all packages built after the new gcc hits the buildroots.
- Proposal owners:
Build gcc in f30, rebuild packages that have direct dependencies on exact gcc version (libtool, annobin, gcc-python-plugin).
- Other developers: First few days/weeks just voluntary rebuilds using
the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.
- Release engineering: . Mass rebuild requested for F30.
- Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact == No impact
== How To Test == 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.
== User Experience == Users will be able to see compiled code improvements and use the newly added features. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, or, if they detect a GCC bug, report it.
== Dependencies == libtool, annobin, gcc-python-plugin depend on exact gcc version, those need to be rebuilt.
== Contingency Plan == 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 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, but worst case we can mass rebuild everything with older gcc again. Jeff Law has performed test mass rebuild on x86_64.
- Contingency mechanism: Revert to older gcc, mass rebuild everything again
- Contingency deadline: Before release
- Blocks release? Yes
- Blocks product? No
== Documentation == http://gcc.gnu.org/gcc-9/
== Release Notes == Fedora 30 comes with GCC 9.1 as primary compiler, see http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it.
I, for one, am excited for GCC 9. Having the GNU D Compiler in Fedora will make things tons easier for having software written in D be able to have the same hardening applied to it that we have for C/C++ programs.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Jan 21, 2019 at 03:27:23PM -0500, Neal Gompa wrote:
On Mon, Jan 21, 2019 at 3:17 PM Ben Cotton bcotton@redhat.com wrote:
[This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo]
I think we want this to go through. The new version is already packaged and I know some work has been done to resolve compilation failures. There's still plenty of time to resolve the remaining issues.
It would also be very awkward to *not* allow this: gcc has already been built in F30, so we'd need to bump the epoch and build a lower version after branching if we want to keep using 8.x in F30. That'd not be pretty.
== Release Notes == Fedora 30 comes with GCC 9.1 as primary compiler, see http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it.
I, for one, am excited for GCC 9. Having the GNU D Compiler in Fedora will make things tons easier for having software written in D be able to have the same hardening applied to it that we have for C/C++ programs.
I certainly would be very disappointed to not see the latest release of gcc in Fedora. The release notes are underwhelming, but I expect there are many improvements to look forward to. For example, I know there are some new diagnostics (we fixed two minor bugs in systemd because of them).
Zbyszek
On Mon, Jan 21, 2019 at 10:36:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
I certainly would be very disappointed to not see the latest release of gcc in Fedora. The release notes are underwhelming, but I expect there are many improvements to look forward to. For example, I know there are some new diagnostics (we fixed two minor bugs in systemd because of them).
The release notes are WIP, more will come when it is written, many new features are just not described there yet.
Jakub
----- Original Message -----
From: "Jakub Jelinek" jakub@redhat.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, January 21, 2019 10:51:32 PM Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
The release notes are WIP, more will come when it is written, many new features are just not described there yet.
One of my packages broke because gcc now prints line numbers with error messages. Just in case anyone else is facing similar issue.
Jakub _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Jan 29, 2019 at 07:07:02AM -0500, Siteshwar Vashisht wrote:
----- Original Message -----
From: "Jakub Jelinek" jakub@redhat.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, January 21, 2019 10:51:32 PM Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
The release notes are WIP, more will come when it is written, many new features are just not described there yet.
One of my packages broke because gcc now prints line numbers with error messages. Just in case anyone else is facing similar issue.
'-fno-diagnostics-show-caret' By default, each diagnostic emitted includes the original source line and a caret '^' indicating the column. This option suppresses this information. The source line is truncated to N characters, if the '-fmessage-length=n' option is given. When the output is done to the terminal, the width is limited to the width given by the 'COLUMNS' environment variable or, if not set, to the terminal width.
'-fno-diagnostics-show-labels' By default, when printing source code (via '-fdiagnostics-show-caret'), diagnostics can label ranges of source code with pertinent information, such as the types of expressions:
printf ("foo %s bar", long_i + long_j); ~^ ~~~~~~~~~~~~~~~ | | char * long int
This option suppresses the printing of these labels (in the example above, the vertical bars and the "char *" and "long int" text).
'-fno-diagnostics-show-line-numbers' By default, when printing source code (via '-fdiagnostics-show-caret'), a left margin is printed, showing line numbers. This option suppresses this left margin.
Jakub
On Mon, Jan 21, 2019 at 4:38 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I think we want this to go through. The new version is already packaged and I know some work has been done to resolve compilation failures. There's still plenty of time to resolve the remaining issues.
I agree, mostly because getting the new GCC in fits well with our "First" foundation (assuming there aren't show-stopper bugs, etc). But...
It would also be very awkward to *not* allow this: gcc has already been built in F30, so we'd need to bump the epoch and build a lower version after branching if we want to keep using 8.x in F30. That'd not be pretty.
...this is a bad reason to approve a change, IMO. In order for the Change process to work as intended, Changes should be submitted and approved before being implemented.
On 21. 01. 19 23:42, Ben Cotton wrote:
On Mon, Jan 21, 2019 at 4:38 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I think we want this to go through. The new version is already packaged and I know some work has been done to resolve compilation failures. There's still plenty of time to resolve the remaining issues.
I agree, mostly because getting the new GCC in fits well with our "First" foundation (assuming there aren't show-stopper bugs, etc). But...
It would also be very awkward to *not* allow this: gcc has already been built in F30, so we'd need to bump the epoch and build a lower version after branching if we want to keep using 8.x in F30. That'd not be pretty.
...this is a bad reason to approve a change, IMO. In order for the Change process to work as intended, Changes should be submitted and approved before being implemented.
Exactly. I'd very much vote +1 for a gcc update, but this is not a way to do it.
This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing.
The process is roughly:
* change proposal * approval * do it
Not:
* do it * change proposal * what goes here exactly?
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing.
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed.
Jakub
On 22. 01. 19 10:29, Jakub Jelinek wrote:
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing.
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed.
Thanks.
On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote:
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better.
It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone".
On ti, 22 tammi 2019, Matthew Miller wrote:
On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote:
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better.
It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone".
To add to what Matthew said, I'll show another example:
https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules was passed in Fedora 29 without real communication with actual complex users of nss databases in Fedora (FreeIPA, Dogtag) even though we are working in a common understanding that something like that was needed.
As result, it broke use of SoftHSM in FreeIPA and Dogtag and continues to be a blocker for our effort to add support of hardware-based security modules in FreeIPA. We have to deal with the fact that now a lot of work have to be directed into workarounding what looked as a nice logical global change in Fedora.
Needless to say, neither FreeIPA nor Dogtag were mentioned in the change and weren't consulted.
On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote:
On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote:
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better.
It also be of historical importance later on - it documents why and when the change was done for future generations, who might no longer remember the reasoning.
There might be even cases where you find software referencing some strange other project, only to find two old Fedora change pages, one documenting the project being added to Fedora and another one documenting it being replaced by something else later on.
This can be really helpful when hunting down obscure bugs or untangling reasons for past design decisions.
It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone".
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Jan 22, 2019 at 3:35 PM Martin Kolman mkolman@redhat.com wrote:
On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote:
On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote:
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better.
It also be of historical importance later on - it documents why and when the change was done for future generations, who might no longer remember the reasoning.
There might be even cases where you find software referencing some strange other project, only to find two old Fedora change pages, one documenting the project being added to Fedora and another one documenting it being replaced by something else later on.
I don't think the Change process actually helps that. If anything, some of the Change pages just contribute to that.
This can be really helpful when hunting down obscure bugs or untangling reasons for past design decisions.
I mean this in the most constructive way, but the Change process is not a design/architecture process. It is a collection of things that individual teams want to do that impacts the rest of the distro, which get approved if nobody objects (or notices too late). A design decision implies an overall architecture to the distribution that is not really present in Fedora.
It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone".
Perhaps I have a tinted view at this point, but I think Fedora has to outgrown the Change process. At the very least, turn it into something that is far less rubber-stampy and more coordinated and planned. Things like the yearly GCC rebase should be fundamental requirements that drive other actions, not something that has to be remembered to be filed in on a wiki every year as if we suddenly would stop doing that if the page didn't get created one time. E.g. we know we'll update GCC in a similar window of time year to year, so if we know that then perhaps we can use it to start articulating what a Fedora Platform really means. Perhaps we use that to drive a lifecycle for a particular ring/platform/whatever that other applications can build and rely on.
I happened to sit in on two talks today that had pieces that resonated with me around affecting change, and how we tell ourselves we work in some particular way but in reality we are doing something else. We keep circling around a lot of things in Fedora that we want to investigate or change or improve, but then we continue to do the same things day in and day out. Perhaps instead of looking for completely new ways to do things, we can look at what we *really* do and not what we tell ourselves we do, and correct or build from those things towards what we want.
josh
On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek jakub@redhat.com wrote:
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing.
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed.
Sorry for digging up this thread, but since this is a recurring change it appears that the mass rebuild is not enough by itself. As of today lcov doesn't work with GCC 9.x [1] and it would be nice if either:
- gcc provided an option to use a previous gcov format when a new one lands (I understand it makes things more complicated) - the Fedora lcov spec would run `make test` in a %check section
Ideally both for the sake of continuity/easier transitions. At the very least we would learn with the latter at mass rebuild time that such a problem exists.
TIL that lcov is a noarch package, I had no idea! And fortunately clang and llvm-cov are still using the old format so for now I can still build code coverage reports but it's a bit annoying to discover this after upgrading.
Dridi
On Mon, May 13, 2019 at 07:42:16PM +0200, Dridi Boukelmoune wrote:
On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek jakub@redhat.com wrote:
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing.
I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007).
That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed.
Sorry for digging up this thread, but since this is a recurring change it appears that the mass rebuild is not enough by itself. As of today lcov doesn't work with GCC 9.x [1] and it would be nice if either:
- gcc provided an option to use a previous gcov format when a new one
lands (I understand it makes things more complicated)
No, we certainly don't want to diverge from gcc upstream here, and gcc upstream doesn't have that.
- the Fedora lcov spec would run `make test` in a %check section
lcov maintainers have been told they should use the json intermediate format from gcov -i instead of trying to parse the binary data.
Jakub
On Mon, May 13, 2019 at 7:57 PM Jakub Jelinek jakub@redhat.com wrote: <snip>
Sorry for digging up this thread, but since this is a recurring change it appears that the mass rebuild is not enough by itself. As of today lcov doesn't work with GCC 9.x [1] and it would be nice if either:
- gcc provided an option to use a previous gcov format when a new one
lands (I understand it makes things more complicated)
No, we certainly don't want to diverge from gcc upstream here, and gcc upstream doesn't have that.
My idea was rather to bring the suggestion upstream if it is relevant :)
- the Fedora lcov spec would run `make test` in a %check section
lcov maintainers have been told they should use the json intermediate format from gcov -i instead of trying to parse the binary data.
Well, not everyone runs Fedora so lcov will still have to support the binary format for platforms that don't adopt new GCC versions as fast.
I hope json support was what they were hoping to get done before May from the github issue I linked. But as a gcc+gcov+lcov user, that also requires me as an end-user to actively run gcov and lcov with the right set of flags once lcov support is here. That also means that if I have automation in place that expects to work with either GCC or LLVM toolchains, it makes things more complicated if I need my build system to work not only for me on Fedora 30 but for other team members working on the same project but on different operating systems.
Hence my comment regarding compatibility when the binary format changes. Again, if that is relevant.
I personally work with both toolchains, because each major release usually brings new helpful warnings or diagnostics. And for that matter I'm really happy to be on Fedora and act as a canary to learn what's coming.
Dridi
On Mon, May 13, 2019 at 10:44:45PM +0200, Dridi Boukelmoune wrote:
On Mon, May 13, 2019 at 7:57 PM Jakub Jelinek jakub@redhat.com wrote:
<snip> > > Sorry for digging up this thread, but since this is a recurring change > > it appears that the mass rebuild is not enough by itself. As of today > > lcov doesn't work with GCC 9.x [1] and it would be nice if either: > > > > - gcc provided an option to use a previous gcov format when a new one > > lands (I understand it makes things more complicated) > > No, we certainly don't want to diverge from gcc upstream here, and gcc > upstream doesn't have that.
My idea was rather to bring the suggestion upstream if it is relevant :)
- the Fedora lcov spec would run `make test` in a %check section
That won't actually fix the problem - it'd just mean that lcov FTBFS and likely get thrown out of Fedora entirely.
lcov maintainers have been told they should use the json intermediate format from gcov -i instead of trying to parse the binary data.
Well, not everyone runs Fedora so lcov will still have to support the binary format for platforms that don't adopt new GCC versions as fast.
This has been reported to upstream lcov community every time they break on new GCC releases & I've backported fixes to Fedora once they are available. Most recently I reported the incompatibility with gcc9 way back in January this year
https://github.com/linux-test-project/lcov/issues/58
I can't do anything to fix lcov in Fedora until upstream provides the fixes.
Regards, Daniel
On 21. 01. 19 21:16, Ben Cotton wrote:
[This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo]
https://fedoraproject.org/wiki/Changes/GCC9
== Summary == Switch GCC in Fedora 30 to 9.x.y...
AFAIK this already happened.
What do I miss?
Hi,
Ben Cotton wrote on Mon, Jan 21, 2019 at 03:16:56PM -0500:
== Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide.
(writing "today" in a change page that stays on a wiki can be confusing if it gets updated later on)
- Other developers: First few days/weeks just voluntary rebuilds using
the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.
I don't have packages to rebuild (evil lurker here), but love to test on some programs I contribute to. Is there any plan to have a copr with gcc+libtools for fedora 29 or would that be too much extra work at this point?
I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around.
It's probably just me being lazy, though; I'll figure something out if there is no such plan :)
Thanks,
On 22/01/19 08:52 +0100, Dominique Martinet wrote:
Hi,
Ben Cotton wrote on Mon, Jan 21, 2019 at 03:16:56PM -0500:
== Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide.
(writing "today" in a change page that stays on a wiki can be confusing if it gets updated later on)
- Other developers: First few days/weeks just voluntary rebuilds using
the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.
I don't have packages to rebuild (evil lurker here), but love to test on some programs I contribute to. Is there any plan to have a copr with gcc+libtools for fedora 29 or would that be too much extra work at this point?
I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around.
That's what 'mock' is for.
It's probably just me being lazy, though; I'll figure something out if there is no such plan :)
It's really easy to build it yourself: https://gcc.gnu.org/wiki/InstallingGCC
Installing binutils is also simple. Build binutils and install it first, then build GCC to use the same prefix as you installed binutils to, and the new GCC will automatically use the new GCC.
Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +0000:
I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around.
That's what 'mock' is for.
Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc.
It's probably just me being lazy, though; I'll figure something out if there is no such plan :)
It's really easy to build it yourself: https://gcc.gnu.org/wiki/InstallingGCC
Installing binutils is also simple. Build binutils and install it first, then build GCC to use the same prefix as you installed binutils to, and the new GCC will automatically use the new GCC.
Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.)
Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works.
Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/
I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed - libgcc-8.2.1-6.fc29.i686 has inferior architecture - libgcc-8.2.1-2.fc29.i686 has inferior architecture - cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed - cannot install the best candidate for the job
while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit)
So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work.
On Sat, 26 Jan 2019, Dominique Martinet wrote:
Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +0000:
I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around.
That's what 'mock' is for.
Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc.
It's probably just me being lazy, though; I'll figure something out if there is no such plan :)
It's really easy to build it yourself: https://gcc.gnu.org/wiki/InstallingGCC
Installing binutils is also simple. Build binutils and install it first, then build GCC to use the same prefix as you installed binutils to, and the new GCC will automatically use the new GCC.
Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.)
Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works.
Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/
I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed
- libgcc-8.2.1-6.fc29.i686 has inferior architecture
- libgcc-8.2.1-2.fc29.i686 has inferior architecture
- cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64
- cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64
- package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed
- cannot install the best candidate for the job
while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit)
So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work.
The problem is your gcc build requires libgcc_s.so.1 which is the i386 version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has gone wrong in your build process.
Michael Young
Thank you two for the answer.
YOUNG, MICHAEL A. wrote on Sat, Jan 26, 2019 at 12:53:18PM +0000:
The problem is your gcc build requires libgcc_s.so.1 which is the i386 version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has gone wrong in your build process.
Eh, even after reading this I was doubting you, but that appears to be true... I guess asking rpm to add a couple of parenthesis after 32bit lib requires to at least look like 64bit libs require and not a simple file require would be asking too much, I never noticed it worked like this for 32bit libs :/
And rightly enough rpm -qp --requires of "my" gcc does have both libgcc_s.so.1 while fc30's libgcc.x86_64 only requires the x86_64 version; interesting given the src.rpm is the same.
I've extracted the rpm and am not quite sure where the auto requires comes from, actually? I thought there was a script doing basically ldd on each executable (as described on the rpm website[1]), but nothing in the gcc package seems to require libgcc_s - what am I missing?
I can't see anything obviously different between both build logs, either copr's[2] or koji's[3] (caution: files are 10MB (compressed) and 55MB respectively); the logs are too different to diff because of parallel build but at least lines containing "libgcc_s" are similar enough...
[1] http://ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html [2] https://copr-be.cloud.fedoraproject.org/results/martinetd/gcc9/fedora-29-x86... [3] https://kojipkgs.fedoraproject.org//packages/gcc/9.0.1/0.1.fc30/data/logs/x8...
Will look into how autodepends works a bit more, I'm curious why this is different.
Thanks,
Am Montag, den 21.01.2019, 15:16 -0500 schrieb Ben Cotton:
- Proposal owners:
Build gcc in f30, rebuild packages that have direct dependencies on exact gcc version (libtool, annobin, gcc-python-plugin).
Did not happen. Rawhide buildroot was broken yesterday around 9:50 UTC. I was doing the rebuilds about one hour *after* GCC-9 was build, just to have a working buildroot on Koji again [1].
gcc-python-plugin wasn't rebuilt until I triggered the build this morning and the package actually is FTBFS due to GCC-9 [2].
This should have been done in a proper chain-build. If the change owner does not have the needed powers for rebuilding other packages, help and coordination from a provenpackager should have been requested *prior* to just dropping in a new major version of GCC.
Anyways, the intention to build a new major version of GCC should have been announced at least one week *before* silently dropping it into Rawhide.
== Contingency Plan == 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 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, but worst case we can mass rebuild everything with older gcc again. Jeff Law has performed test mass rebuild on x86_64.
Where are the results of that test mass-rebuild to be found? How much is the fallout in these rebuilds?
At least one of my critpath packages (libxcrypt) would have been FTBFS due to GCC-9, if I wouldn't have pushed an immediate fix [3].
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] https://bugzilla.redhat.com/show_bug.cgi?id=1668175 [3] https://github.com/besser82/libxcrypt/issues/76
On Mon, 21 Jan 2019 at 21:27, Ben Cotton bcotton@redhat.com wrote: [..]
== User Experience == Users will be able to see compiled code improvements and use the newly added features. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, or, if they detect a GCC bug, report it.
FTR only. Just tested gcc 9.0.0 on one of my projects and seems like gcc 9 is producilng slightly bigger code compare to gcc 8.2.1.
https://github.com/kloczek/tvision/commit/4cf6f4e3f647f67eac886c5a4264e8b631...
kloczek
On Mon, Jan 21, 2019 at 03:16:56PM -0500, Ben Cotton wrote:
[This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo]
https://fedoraproject.org/wiki/Changes/GCC9
== Summary == Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 31.
== Owner ==
- Name: [[User:jakub| Jakub Jelínek]]
- Email: jakub@redhat.com
== Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide.
== User Experience == Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, or, if they detect a GCC bug, report it.
Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus warnings for code using anonymous struct initializers during assignments:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 https://bugzilla.redhat.com/show_bug.cgi?id=1669489
It is quite an ununfortunate bug as it is not straightforward to workaround the bogus warning by changing code, while we also don't want to disable -Wjump-misses-init since it is a useful/important warning in general. So we'd really like to see the regression fixed before F30 GA.
Regards, Daniel
On Tue, Jan 29, 2019 at 12:51:25PM +0000, Daniel P. Berrangé wrote:
Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus warnings for code using anonymous struct initializers during assignments:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 https://bugzilla.redhat.com/show_bug.cgi?id=1669489
It is quite an ununfortunate bug as it is not straightforward to workaround the bogus warning by changing code, while we also don't want to disable -Wjump-misses-init since it is a useful/important warning in general. So we'd really like to see the regression fixed before F30 GA.
That is not a false positive, you are crossing initialization of the compound literal. Older GCC versions mistakenly haven't put the automatic variables for the compound literals into the right scope. Yes, in your case you are not accessing the compound literal in the cleanup: code, but that is exactly the same case when you get a warning for: if (whatever) goto cleanup;
int i = 26;
cleanup: return 0;
Jakub
On Tue, Jan 29, 2019 at 01:56:19PM +0100, Jakub Jelinek wrote:
On Tue, Jan 29, 2019 at 12:51:25PM +0000, Daniel P. Berrangé wrote:
Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus warnings for code using anonymous struct initializers during assignments:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 https://bugzilla.redhat.com/show_bug.cgi?id=1669489
It is quite an ununfortunate bug as it is not straightforward to workaround the bogus warning by changing code, while we also don't want to disable -Wjump-misses-init since it is a useful/important warning in general. So we'd really like to see the regression fixed before F30 GA.
That is not a false positive, you are crossing initialization of the compound literal. Older GCC versions mistakenly haven't put the automatic variables for the compound literals into the right scope.
The variable was already initialized right at the start. The compound literal is just a short-hand for later changing the values in several fields of the struct at once. This is no different to manually assigning new values to each individual field one at a time. eg
struct demo demo = {0};
...some code with a goto...
demo = (struct demo) { .cmd = "foo" };
is no different from
struct demo demo = {0};
...some code with a goto...
demo.cmd = "foo"
and neither should generate warnings about missing initializers with gotos.
Yes, in your case you are not accessing the compound literal in the cleanup: code, but that is exactly the same case when you get a warning for:
Even if we were accessing the the variable in the cleanup code, it would not be a missing initializer, as the variable was initialized at the time it was declared before any goto.
if (whatever) goto cleanup;
int i = 26;
cleanup: return 0;
This is a completely different scenario, as it is jumping over the declaration of the variable and its only initializer.
Regards, Daniel
On Tue, Jan 29, 2019 at 01:04:25PM +0000, Daniel P. Berrangé wrote:
The variable was already initialized right at the start. The compound literal is just a short-hand for later changing the values in several fields of the struct at once. This is no different to manually assigning new values to each individual field one at a time. eg
struct demo demo = {0};
...some code with a goto...
demo = (struct demo) { .cmd = "foo" };
No, I wasn't talking about the demo variable, the warning is not about demo variable. The warning is about the compound literal variable. That is an anonymous (when used at block scope automatic) variable, kind like: struct demo __complit = { .cmd = "foo" }; demo = __complit; and with the goto you are crossing initialization of that variable. When you aren't taking address of this, the optimizers will likely optimize the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" } that address could be used later on in the function, dereferenced etc.
Jakub
On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
On Tue, Jan 29, 2019 at 01:04:25PM +0000, Daniel P. Berrangé wrote:
The variable was already initialized right at the start. The compound literal is just a short-hand for later changing the values in several fields of the struct at once. This is no different to manually assigning new values to each individual field one at a time. eg
struct demo demo = {0};
...some code with a goto...
demo = (struct demo) { .cmd = "foo" };
No, I wasn't talking about the demo variable, the warning is not about demo variable. The warning is about the compound literal variable. That is an anonymous (when used at block scope automatic) variable, kind like: struct demo __complit = { .cmd = "foo" }; demo = __complit; and with the goto you are crossing initialization of that variable.
Urgh. I would never have understood that from the warning message :-( It is complaining about something that doesn't even exist as far as I was concerned
When you aren't taking address of this, the optimizers will likely optimize the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" } that address could be used later on in the function, dereferenced etc.
Is it practical to get the warning supressed when code is not taking the address of the anonymous var ?
If not then we pretty much have to abandon use of these anonymous compound initializers for re-assigning existing variables :-(
Regards, Daniel
On Tue, Jan 29, 2019 at 01:22:19PM +0000, Daniel P. Berrangé wrote:
On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
On Tue, Jan 29, 2019 at 01:04:25PM +0000, Daniel P. Berrangé wrote:
The variable was already initialized right at the start. The compound literal is just a short-hand for later changing the values in several fields of the struct at once. This is no different to manually assigning new values to each individual field one at a time. eg
struct demo demo = {0};
...some code with a goto...
demo = (struct demo) { .cmd = "foo" };
No, I wasn't talking about the demo variable, the warning is not about demo variable. The warning is about the compound literal variable. That is an anonymous (when used at block scope automatic) variable, kind like: struct demo __complit = { .cmd = "foo" }; demo = __complit; and with the goto you are crossing initialization of that variable.
Urgh. I would never have understood that from the warning message :-( It is complaining about something that doesn't even exist as far as I was concerned
When you aren't taking address of this, the optimizers will likely optimize the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" } that address could be used later on in the function, dereferenced etc.
Is it practical to get the warning supressed when code is not taking the address of the anonymous var ?
If not then we pretty much have to abandon use of these anonymous compound initializers for re-assigning existing variables :-(
Let me second that. In systemd upstream we have been slowly changing code to use compound initializers instead in places where "all" fields of a structure would be assigned. With explicit list it's easy to miss some fields when the code is changed, and compound initialization avoids this risk. It's much more elegant.
Zbyszek
* Jakub Jelinek:
On Tue, Jan 29, 2019 at 12:51:25PM +0000, Daniel P. Berrangé wrote:
Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus warnings for code using anonymous struct initializers during assignments:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 https://bugzilla.redhat.com/show_bug.cgi?id=1669489
It is quite an ununfortunate bug as it is not straightforward to workaround the bogus warning by changing code, while we also don't want to disable -Wjump-misses-init since it is a useful/important warning in general. So we'd really like to see the regression fixed before F30 GA.
That is not a false positive, you are crossing initialization of the compound literal. Older GCC versions mistakenly haven't put the automatic variables for the compound literals into the right scope. Yes, in your case you are not accessing the compound literal in the cleanup: code, but that is exactly the same case when you get a warning for:
if (whatever) goto cleanup;
int i = 26;
cleanup: return 0;
I think it's more like getting a warning for this:
int i = 5;
if (whatever) goto cleanup;
i = 26; // …
cleanup: return 0;
In fact, this results in warning, too:
i = (struct { int value; }) { 26 }.value;
As Joseph pointed out on the upstream PR, the warning refers to the internal variable used to store the compound literal, which the programmer did not spell out explicitly.
I'm not sure if it is possible that the skipped initialization leads to undefined behavior, without also involving a pointer to an object that goes out of scope.
Thanks, Florian
-
Alexander Bokovoy -
Ben Cotton -
Björn 'besser82' Esser -
Daniel P. Berrangé -
Dominique Martinet -
Dridi Boukelmoune -
Florian Weimer -
Jakub Jelinek -
Jonathan Wakely -
Josh Boyer -
Martin Kolman -
Matthew Miller -
Miro Hrončok -
Neal Gompa -
Siteshwar Vashisht -
Tomasz Kłoczko -
YOUNG, MICHAEL A. -
Zbigniew Jędrzejewski-Szmek