Re: GCC 4.6 performance regressions
> While I appreciate Phoronix as a booster site, their benchmarking > practice often seems very dodgy; I'd take the results with a large grain > of salt The main reason I posted the link in the first place was because it was reflecting my own emperical evidence for the application I am working on; the march/mtune flags (on various corei* cpus) are actually detrimental to performance (albeit by at most 10% - but still, not the performance boost I was hoping for). I had been trying for the last few weeks to strip down my application into a mini-benchmark I could create a PR out of, however it is tougher than expected and was hoping the Phoronix article was going to offer a quicker route to finding performance regressions than my code - as their coverage was a lot wider. Anyway, apparently this is not the case, so back to my original work... Would it not be in the best interests for both GCC and Phoronix to rectify the problems in their benchmarks? Could we not contact the authors of the article and point out how they can make their benchmarks better? I would be happy to contact them myself, however I think it would be far more effective (and valid) coming from a GCC maintainer. Points they have apparently missed so far are; - clarify which compiler flags they are using - don't run make -j when looking at compile times - ensure they are using --enable-checking=release when benchmarking a snapshot - in general, as much information as possible as to their setup and usage, to make the results easily repeatable Out of interest, has their been much communication in the past between GCC and Phoronix to address any of these issues in their previous benchmarks? Tony
GCC 4.6 performance regressions
Hi, The following article has a fairly comprehensive set of benchmarks run against all the current stable releases of GCC as well as 4.6.0. http://www.phoronix.com/scan.php?page=article&item=intel_avx_gcc&num=1 There are some great results for 4.6.0 in there, which is very good news (congratulations!). However there are also some performance regressions, some of which are fairly significant. I have a few questions regarding these regressions; 1. Can any of these results be logged as 4.6 regressions in bugzilla, or are they too general as they stand to be of any use to anyone? 2. If not, any advice on how I can break these up into smaller chunks that would be of use? 3. Is there a single person assigned to looking at performance issues, or is this handled by the community as a whole? 4. Is there a benchmark suite similar to the test suite, that these benchmarks could be added to? Thanks, Tony
Re: Bugzilla permissions
>> Could someone with the powers please modify my permissions to the above? > > I will do that if a gcc maintainer vouches for you. For the record, this situation has now been resolved and I can edit the bugs as requested. Many thanks, Tony
Re: Bugzilla permissions
Hi, On Wed, Jan 26, 2011 at 2:36 PM, Richard Guenther wrote: > I have added you to the reconfirmers group, please check if that makes > it work. Thanks, however I am still unable to make the changes in bugzilla, specifically; - modify "known to fail"/"known to work" fields - transition a bug status from UNCONFIRMED to NEW - change "Target Milestone" - potentially change priority/severity Could someone with the powers please modify my permissions to the above? (as an aside, shouldn't modifying the "known to fail/work" fields be enabled by default for all?) Many thanks, Tony
Re: Bugzilla permissions
Thanks. Whilst I can see the change you made in my preferences permissions screen, I don't seem to be able to edit any more of the fields than I could before (I have logged out and back in again). Tony On Wed, Jan 26, 2011 at 2:36 PM, Richard Guenther wrote: > On Wed, Jan 26, 2011 at 3:32 PM, Tony Poppleton > wrote: >> Hi, >> >> I am working on some GCC bug triage, and am unable to edit the "known >> to fail/work" fields in Bugzilla, as well as modify the status of a >> bug. >> >> On the overseers list, Ian Lance Taylor suggested I post to this list >> requesting a gnu.gcc.org email account, as they come with all the >> necessary privileges. Could I please obtain a gcc email account? > > I have added you to the reconfirmers group, please check if that makes > it work. > > Richard. > >> Many thanks, >> Tony >> >
Bugzilla permissions
Hi, I am working on some GCC bug triage, and am unable to edit the "known to fail/work" fields in Bugzilla, as well as modify the status of a bug. On the overseers list, Ian Lance Taylor suggested I post to this list requesting a gnu.gcc.org email account, as they come with all the necessary privileges. Could I please obtain a gcc email account? Many thanks, Tony
Re: Bug triage
Thanks for the feedback. > Moving the test case into an attachment won't be useful. What would be > useful is recasting the test case into a form which can be used in the > gcc testsuite, if possible Whilst I would like to be able to submit new test cases as I go, as you (Ian) pointed out this may be too difficult for missed-optimization bugs as I cannot confirm if the assembler is fixed - I can only confirm if it shows the inefficiency as listed in the bug description. Anyway, I will see what I can manage. Out of interest, is there a way of linking bugs in the bug database with their test case in the gcc test-suite, and vice-versa? There doesn't appear to be a field for this in the bug report. > > 5. Similarly, if I mark a bug as known to work in 4.5.2, will this > > lead to it eventually being closed? Just to clarify what Joseph was saying on this point, it seems that in order to help close off any bugs, I would need to run the test on 4 versions of gcc; 4.3.5, 4.4.5, 4.5.2 and trunk (4.6.0), and confirm it works for all of them. What exact gcc code should I use for this? - the latest stable build for each version? - or, the latest code from each branch? - or, the latest snapshot release for each branch? It seems to me there are pros and cons of each, so it isn't clear which is the best one. In particular, if I don't use a stable release branch, then what version should I put for the "Known to fail/work"? For example, if I use the trunk and I mark bugs as "Known to fail" in "4.6.0", and the bug is eventually fixed before 4.6.0 is shipped, then the field will be incorrectly set. > There are very many UNCONFIRMED bugs. If you can confirm that such a > bug really is a bug in GCC and is still present on trunk, then moving it to > NEW is useful. Whilst I would like to be able to do this, as a first time contributor to the project do I really have the authority to mark a bug as NEW? Otherwise what is stopping the original reporter from just marking the bug as NEW and effectively skipping the UNCONFIRMED state all together? I have a few more questions about the whole bug management process and how I may contribute... To take a random example, enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902 has been open since 2006, it has a fairly comprehensive list of "known to fail" versions (presumably versions that were current at the time), and it has several comments. However it remains in the UNCONFIRMED state, and has never had the "Target Milestone" set. I appreciate that optimizing inline asm may be a rare use case, especially when it works without using inline asm (as per comments), however it is a valid enhancement nonetheless (and presumably the actual use case is more complicated than reported in the bug description). If I were to test this enhancement on the 4 versions of gcc and confirm it is still an open enhancment, then should it be marked as NEW, with a "Target Milestone" of 4.6.0, and the priority potentially lowered to P4 or P5 (given it is rare and old)? Regards, Tony
Bug triage
Hi, I would like to help with some gcc bug triage, and have a few questions about doing so. 1. My plan is to start testing bugs against the latest stable build (4.5.2), on an Intel x86-64 architecture (possibly also testing 32 bit bugs). My main focus will be on "missed-optimizations", although I will try and do others too. I have read the http://gcc.gnu.org/bugs/management.html page, so it seems the main thing I will be doing is setting one of the "Known to pass/fail" fields to "4.5.2". Is there anything else that I can do that would be of use to gcc developers? (short of fixing the bug : ) For example, in cases where a bug doesn't have a test case as an attachment, but instead embedded in the description, would it be of use for me to create the attachment? 2. A large number of bugs seem to not be targetted for any particular release, e.g. of the 4389 open bugs, only 296 are listed as targetted for 4.6.0. Why is there such a discrepency? Incidentally, my main focus will be on these untargetted bugs rather than on bugs that are already scheduled to be fixed. 3. If I mark a bug as known to fail in 4.5.2, will someone else then schedule it to be fixed in 4.6.0? 4. In general, who is responsible for setting the target release field? 5. Similarly, if I mark a bug as known to work in 4.5.2, will this lead to it eventually being closed? Thanks, Tony
