Re: GCC var-tracking-assignments: testing and bug reports appreciated
Dave Airlie airlied at redhat.com writes:
On Thu, 2009-09-10 at 21:27 +, Mark Wielaard wrote:
Although it obviously would have been far nicer to have had this all in
the mass rebuild, there were multiple test builds against rawhide packages.
I
did a build of the rawhide kernel package using jakub's gcc-vta and lxo used
that to post results of testing to the gcc list, which helped get it
accepted
upstream, which is a requirement for it to make it into fedora, etc.
Sorry, this wasn't more visible.
Wierdly the first package that broke when this was pushed was the
kernel
Yes :{ Which does proof Jesse's point of course.
There is no substitute for just dumping the code into rawhide
to give it a thorough testing... The original plan
Jakub had was to do a complete out-of-repo mass-rebuild before
adding it, but ran out of time, so that would have made it hit
rawhide even later... And Alex has been fast fixing any issues.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On 09/10/2009 06:27 PM, Tom Lane wrote: Mark Wielaard m...@redhat.com writes: Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. ISTM the major argument in favor of letting this in now, namely better debuginfo data, is essentially moot because it missed the mass rebuild. The majority of packages are going to go out with old debuginfo. I'm not sure that's entirely true. Right now, a frequent debugging workflow for me is something like: 1) discover the problem I'm seeing is in $PACKAGE 2) check out $PACKAGE from cvs and make a test-srpm 3) build it without optimizations 4) wedge it into my test environment 5) debug! With better debuginfo generation in gcc, this workflow remains the same, but it's possible that a) I may not have to turn of optimizations in step #3, which can be a nontrivial difference depending on the package, and b) I may get better results with step #5 . So there is some advantage to doing this now, though it's not as great as it could be had it been done within Fedora's unrealistic schedule. -- Peter When in doubt, debug-on-entry the function you least suspect has anything to do with something. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Sep 11, 2009, John Reiser jrei...@bitwagon.com wrote: Not fast enough to avoid a two-day slip in rawhide kernels. ?!? A work-around that enabled a successful kernel build was offered within minutes. A patch that fixed the bug was offered within hours. A GCC with the fix was available about half a day after the initial bug report, and the kernel built with the newer GCC (but without newer debug info) was already available at that point. https://bugzilla.redhat.com/show_bug.cgi?id=521322 This bug was opened before the new GCC. Exactly *one* kernel build failed because of the new GCC feature. I can't find any evidence that this bug is in any way related with VTA or with the new GCC. So how do you get from “GCC debug info was fixed, with one kernel build and a few hours as casualty” to “two-day slip in rawhide kernels”? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On 09/11/2009 12:03 PM, Alexandre Oliva wrote: On Sep 11, 2009, John Reiserjrei...@bitwagon.com wrote: snip https://bugzilla.redhat.com/show_bug.cgi?id=521322 This bug was opened before the new GCC. Exactly *one* kernel build failed because of the new GCC feature. I can't find any evidence that this bug is in any way related with VTA or with the new GCC. Even though there is no known technical connection between 521322 and the hiccup with the new GCC, the hiccup got in the way of communicating and disseminating the work on 521322, by interfering with the normal process of daily rawhide. So how do you get from “GCC debug info was fixed, with one kernel build and a few hours as casualty” to “two-day slip in rawhide kernels”? Yes, 521322 was opened before the new GCC. But fully fixing 521322 (making the software work for my card) has been delayed because the new GCC disrupted the process despite not being an immediate impediment. The first part of 521322 was essentially the same as 520766, and it was marked as duplicate in https://bugzilla.redhat.com/show_bug.cgi?id=521322#c7 with the fix https://bugzilla.redhat.com/show_bug.cgi?id=520766#c4. So I tried to test the fix immediately, by retrieving it directly from Koji late Wednesday afternoon (PDT). That build kernel-2.6.31-0.218.rc9.git2.fc12 failed. The build of the next kernel-2.6.31-0.219.rc9.git2.fc12 succeeded. Yes it did fix the 520766-like problem for me, but it revealed the next bug https://bugzilla.redhat.com/show_bug.cgi?id=521322#c8. That was early evening PDT on Wednesday. There had been no Rawhide report that day, and there was no Rawhide report on Thursday, either, until 2100 PDT, which is 12 to 16 hours later than expected. Today's rawhide still does not fix it: https://bugzilla.redhat.com/show_bug.cgi?id=521322#c13. The no external progress [still broken even though the internal cause has advanced] from the fix for 520766 on Wednesday until today (Friday) overlaps closely with two-day slip in rawhide kernels from Tuesday morning until Thursday evening. To the extent that the GCC hiccup contributed to the lack of a Rawhide report kernel in that interval, then GCC is a direct cause. If I had relied solely on Rawhide report, then there would have been no progress from Tuesday morning to Thursday evening. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
John Reiser (jrei...@bitwagon.com) said: If I had relied solely on Rawhide report, then there would have been no progress from Tuesday morning to Thursday evening. The delays in rawhide had nothing to do with the new gcc, FWIW. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
Tom Lane wrote: ISTM the major argument in favor of letting this in now, namely better debuginfo data, is essentially moot because it missed the mass rebuild. The majority of packages are going to go out with old debuginfo. Well, all the frequently rebuilt / frequently updated packages will pick up the new debuginfo, this includes at least Qt and KDE (though Qt currently trips over a bug in the var tracking and has to disable it, but I'm confident this will get fixed quickly if it isn't already). The GNOME packages will also get it, as 2.28 final is coming out and so the 2.27.x packages will all get replaced. That makes pretty much all the packages of the 2 primary desktops. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Fri, Sep 11, 2009 at 10:44:22PM +0200, Kevin Kofler wrote: the new debuginfo, this includes at least Qt and KDE (though Qt currently trips over a bug in the var tracking and has to disable it, but I'm confident this will get fixed quickly if it isn't already). The GNOME That is fixed already for a few hours. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
Jakub Jelinek wrote: That is fixed already for a few hours. And Qt has now been rebuilt (by rdieter) with var-tracking-assignments enabled: http://koji.fedoraproject.org/koji/buildinfo?buildID=131619 Thanks to all you GCC folks for fixing the bug so quickly! :-) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, Sep 10, 2009 at 12:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Sep 9, 2009 at 11:53 PM, Michel Alexandre Salim michael.silva...@gmail.com wrote: On Tue, Sep 8, 2009 at 9:46 PM, Alexandre Oliva aol...@redhat.com wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. I'd appreciate if you Cc: me on any bug reports you hit that might be related with this new feature (GCC internal compiler errors, verify_ssa failures, crashes, etc). This bug affects LLVM on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=522316 I don't see a more recent pass in Koji. Did you try compiling with -fno-var-tracking-assignments does it help? Weird, I definitely did another build, and yes, it passed with that flag: http://koji.fedoraproject.org/koji/packageinfo?packageID=5646 Regards, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Wed, Sep 09, 2009 at 06:35:09AM -0400, Josh Boyer wrote: On Tue, Sep 08, 2009 at 10:46:26PM -0300, Alexandre Oliva wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? I mean, I'm not asking for much. All I want is an explanation as to why this _has_ to be in F12 and can't be rolled into F13 instead. At first glance, it would make more sense to let the feature get some testing in GCC mainline before we just backport it to Fedora users, so putting it in F13 seems better to me. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, Sep 10, 2009 at 07:32:07AM -0400, Josh Boyer wrote: Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? I mean, I'm not asking for much. All I want is an explanation as to why this _has_ to be in F12 and can't be rolled into F13 instead. At first glance, it would make more sense to let the feature get some testing in GCC mainline before we just backport it to Fedora users, so putting it in F13 seems better to me. Because we really want it in F12, to make e.g. systemtap usable. It got quite a lot of testing already and has been in development for 2 years. Originally it was expected to be merged early in the summer, testing rawhide gccs have been prepared already in early August. There were so far 3 bugreports related to this, 2 of them are already fixed, LLVM build is just needing too much memory on completely insane source (people calling functions with 1375 arguments, 685 out of it are classes with non-trivial ctors passed by value, deserve some punishment) and Alex will look at it today. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, Sep 10, 2009 at 01:43:26PM +0200, Jakub Jelinek wrote: On Thu, Sep 10, 2009 at 07:32:07AM -0400, Josh Boyer wrote: Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? I mean, I'm not asking for much. All I want is an explanation as to why this _has_ to be in F12 and can't be rolled into F13 instead. At first glance, it would make more sense to let the feature get some testing in GCC mainline before we just backport it to Fedora users, so putting it in F13 seems better to me. Because we really want it in F12, to make e.g. systemtap usable. It got quite a lot of testing already and has been in development for 2 years. Originally it was expected to be merged early in the summer, testing rawhide gccs have been prepared already in early August. So systemtap wasn't considered usable before this? I am not a GCC expert, but I can see how this feature would help it. But it was surely usable before this, right? There were so far 3 bugreports related to this, 2 of them are already fixed, LLVM build is just needing too much memory on completely insane source (people calling functions with 1375 arguments, 685 out of it are classes with non-trivial ctors passed by value, deserve some punishment) and Alex will look at it today. I have every confidence that you and Alex will fix all the bugs reported. I also think the code itself is likely fairly stable, and may very well provide some usability wins overall. Your competence as a developer is not, nor ever was, in question so please don't misunderstand my questioning. The largest problem I have with all this is the fact that the release guidelines that everyone else has to follow don't appear to be followed at all in this case. You're introducing a backported feature into a critical path package after Feature freeze, and after a mass-rebuild which would have arguably helped test the hell out of this. Any other maintainer would have to get an exception from rel-eng and/or FESCo in order to do something like this. I don't see why the same requirements don't apply here. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, 2009-09-10 at 08:27 -0400, Josh Boyer wrote: The largest problem I have with all this is the fact that the release guidelines that everyone else has to follow don't appear to be followed at all in this case. You're introducing a backported feature into a critical path package after Feature freeze, and after a mass-rebuild which would have arguably helped test the hell out of this. Any other maintainer would have to get an exception from rel-eng and/or FESCo in order to do something like this. I don't see why the same requirements don't apply here. This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. If GCC is going to get special treatment, we should discuss, agree upon, and document that special treatment to avoid GCC being used as an excuse for others to ignore our policy and procedure. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Sep 10, 2009, Josh Boyer jwbo...@gmail.com wrote: On Wed, Sep 09, 2009 at 06:35:09AM -0400, Josh Boyer wrote: On Tue, Sep 08, 2009 at 10:46:26PM -0300, Alexandre Oliva wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? It helps to Cc: me. There are hundreds of mailing lists I'm in that I don't open every day ;_) As Jakub said, this was planned to go in before. The merge into Fedora was delayed because there was a possibility of upstream rejection, based on opinions voiced some 1 or 2 years ago, when this work was still in early planning and development stages. Indeed, formal acceptance took much longer than anticipated, which is why this hit Fedora rawhide so late in the game. I can surely understand the feeling that, as a feature, it should have respected the feature freeze deadlines. But this feature also happens to be a major bug fix, for debug information in optimized programs way too often used to be incorrect and incomplete, to the point of being pretty much a show-stopper for systemtap and other monitoring, inspection and debugging tools that rely on debug information. As such, I apologize for the delays in getting buy-in from upstream and completing the work needed to get it in, and ask you to please tolerate the delays and the changes, let it into Fedora 12, and enjoy the better-quality debug information while debugging problems in time for Fedora 12 ;-) Thanks, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Sep 10, 2009, Michel Alexandre Salim michael.silva...@gmail.com wrote: This bug affects LLVM on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=522316 I've Cc:ed you on it. Thanks, I'm on it. BTW, I wanted to mention that in the e-mail that started this thread, but failed. You all feel free to get in touch with me on IRC (my nick is lxo) to bring bug reports along these lines to my attention. E-mail is very slow in this regard, as in, I fetch new mail every several hours. I could have started working on this last night, but since I hadn't got notice of it yet, I ended up working on something else that was not quite as urgent ;-( Thanks, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, Sep 10, 2009 at 7:43 AM, Jakub Jelinek ja...@redhat.com wrote: There were so far 3 bugreports related to this, 2 of them are already fixed, LLVM build is just needing too much memory on completely insane source (people calling functions with 1375 arguments, 685 out of it are classes with non-trivial ctors passed by value, deserve some punishment) and Alex will look at it today. That would explain why the previous two builds fail with virtual memory exhaustion errors (not the last one, bizarrely). Thanks, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
Josh Boyer jwboyer at gmail.com writes: On Thu, Sep 10, 2009 at 01:43:26PM +0200, Jakub Jelinek wrote: Because we really want it in F12, to make e.g. systemtap usable. It got quite a lot of testing already and has been in development for 2 years. Originally it was expected to be merged early in the summer, testing rawhide gccs have been prepared already in early August. So systemtap wasn't considered usable before this? I am not a GCC expert, but I can see how this feature would help it. But it was surely usable before this, right? Better debuginfo and better systemtap tracing support is part of https://fedoraproject.org/wiki/Features/SystemtapTracingRefresh which is targetted at F12. But better variable tracking in the dwarf output of gcc will also help other observability tools in Fedora (like the updated gdb/archer). Cheers, Mark -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. I did a build of the rawhide kernel package using jakub's gcc-vta and lxo used that to post results of testing to the gcc list, which helped get it accepted upstream, which is a requirement for it to make it into fedora, etc. Sorry, this wasn't more visible. Cheers, Mark -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
Mark Wielaard m...@redhat.com writes: Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. ISTM the major argument in favor of letting this in now, namely better debuginfo data, is essentially moot because it missed the mass rebuild. The majority of packages are going to go out with old debuginfo. Is there any chance of doing a new mass rebuild now? That would actually provide the intended benefit. Plus, if we see any significant number of failures, it would be sufficient evidence that the update ought to be backed out; whereas if we don't, then it would assuage peoples' entirely legitimate fears. (I entirely agree with the concerns about this being a violation of agreed-on process, btw, and would not be unhappy with a summary rejection as an alternative.) regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, 2009-09-10 at 21:27 +, Mark Wielaard wrote: Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. I did a build of the rawhide kernel package using jakub's gcc-vta and lxo used that to post results of testing to the gcc list, which helped get it accepted upstream, which is a requirement for it to make it into fedora, etc. Sorry, this wasn't more visible. Wierdly the first package that broke when this was pushed was the kernel ;-) Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Tue, Sep 08, 2009 at 10:46:26PM -0300, Alexandre Oliva wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Tue, Sep 8, 2009 at 9:46 PM, Alexandre Oliva aol...@redhat.com wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. I'd appreciate if you Cc: me on any bug reports you hit that might be related with this new feature (GCC internal compiler errors, verify_ssa failures, crashes, etc). This bug affects LLVM on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=522316 I've Cc:ed you on it. Thanks, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Wed, Sep 9, 2009 at 11:53 PM, Michel Alexandre Salim michael.silva...@gmail.com wrote: On Tue, Sep 8, 2009 at 9:46 PM, Alexandre Oliva aol...@redhat.com wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. I'd appreciate if you Cc: me on any bug reports you hit that might be related with this new feature (GCC internal compiler errors, verify_ssa failures, crashes, etc). This bug affects LLVM on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=522316 I don't see a more recent pass in Koji. Did you try compiling with -fno-var-tracking-assignments does it help? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
GCC var-tracking-assignments: testing and bug reports appreciated
Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. I'd appreciate if you Cc: me on any bug reports you hit that might be related with this new feature (GCC internal compiler errors, verify_ssa failures, crashes, etc). It's very important that any such bugs you run into be reported quickly: I'm going to be around this week, full time, working on this, but my network connectivity will be poor at best next week. In case you suspect a problem might be caused by this new feature, instead of say untagging the GCC build, please instead install a temporary work-around in your package to compile with the flag -fno-var-tracking-assignments. If it compiles with this flag, the you know I'm the culprit. Mentioning the successful use of this work around in the bug report may help prioritize the resolution of bugs. If you follow this path, I suggest also creating a bug report on your package, blocked on the resolution of the GCC bug, so that, once the GCC bug is fixed, you're reminded to remove the work-around. Thanks in advance for your cooperation, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
