Re: proposal for improved management bugzilla priorities/release criteria
On Wed, Feb 11, 2009 at 7:56 PM, Mark Mitchell wrote: > Paolo Bonzini wrote: > >>> I think the only reasonable release criteria is zero P1 regressions over >>> some period. 50 P2 regressions doesn't make a release blocker, neither >>> is 49 P2 regressions a clear sign for a non-blocked release. >> >> I agree. > > I mostly agree. P1 regressions are, by definition, Really Bad. In the > past, we've sometimes had to release in that state because it was clear > that there was no reasonable way to get the P1 regression fixed. But, > that's not what we want to do. > > However, I don't agree that P2 regressions aren't a factor. If we have > a ton of crashing on wrong-code, etc., regressions that adds up to a > release that won't work well for people. In which case the important ones should be P1 ... I'd use P2 for bugs we are comfortable fixing later on the release branch or, if resources force it, not at all for the release. Which apart from exceptions would automatically make wrong-code or rejects-valid, ice-on-valid bugs P1. If they are not regressions or regressions that we knowingly released older versions with they IMHO qualify for P2. > I don't think there can be, or need to be, completely bright-line rules. > We need human beings to use their judgment about when the release is > good enough to go out the door. So, I'm all for guidelines, and I agree > that 49 vs. 50 isn't itself a big deal. But, I think that Paolo's > criterion should not be interpreted literally. Of course. Richard.
Re: proposal for improved management bugzilla priorities/release criteria
Richard Guenther wrote: >> However, I don't agree that P2 regressions aren't a factor. If we have >> a ton of crashing on wrong-code, etc., regressions that adds up to a >> release that won't work well for people. > > In which case the important ones should be P1 ... No, that misses the point. A mass of bugs, each itself not too critical, can still make a release that is of substandard quality. Think of the integral of perceived quality over the intended user-base. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
[graphite] News from the weekly graphite phone call
Hi, This week's notes are posted on the GCC wiki: http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_02_11 Last week I did not announced it, but the notes are also available: http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_02_04 If people want to attend the graphite phone call, please drop me an email. Thanks, Sebastian Pop -- AMD - GNU Tools
Re: proposal for improved management bugzilla priorities/release criteria
>>> However, I don't agree that P2 regressions aren't a factor. If we have >>> a ton of crashing on wrong-code, etc., regressions that adds up to a >>> release that won't work well for people. >> >> In which case the important ones should be P1 ... > > No, that misses the point. A mass of bugs, each itself not too > critical, can still make a release that is of substandard quality. > Think of the integral of perceived quality over the intended user-base. Yes, that was the meaning more-or-less of my "50 P2" criteria. Still, I would like to hear an opinion on what to do with regard to long standing bugs that are clearly not going to be fixed in stage3/4. This was the main point of my message. Paolo
gcc-4.3-20090212 is now available
Snapshot gcc-4.3-20090212 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090212/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 144138 You'll find: gcc-4.3-20090212.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090212.tar.bz2 C front end and core compiler gcc-ada-4.3-20090212.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090212.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090212.tar.bz2 C++ front end and runtime gcc-java-4.3-20090212.tar.bz2 Java front end and runtime gcc-objc-4.3-20090212.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090212.tar.bz2The GCC testsuite Diffs from 4.3-20090205 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[plugins] Comparison of plugin mechanisms
Dear all, Zbigniew and I prepared a page on GCC Wiki comparing several current plugin mechanisms (some parts should be updated) with some suggestions to move forward: http://gcc.gnu.org/wiki/GCC_PluginComparison In case we mixed up or misunderstood something about other plugin efforts, update this page, please ... Basically, we currently see 3 complementary categories of GCC plugins, depending on the nature of the extension: production, experimentation/research, and new pass integration. Each category naturally calls for slightly different API features. Considering that there are already communities behind "production" and "experimental" plugins, we think that it would be better to merge two. We will try to prepare a small patch to support "experimental" plugins by the beginning of next week. In the mean time, would like to know your thoughts on that matter and how should we proceed forward !.. Cheers, Grigori & Zbigniew
Re: proposal for improved management bugzilla priorities/release criteria
Paolo Bonzini wrote: > Still, I would like to hear an opinion on what to do with regard to > long standing bugs that are clearly not going to be fixed in stage3/4. > This was the main point of my message. I don't see any need to do anything different; I think we're all capable of distinguishing at this point. If there were thousands of bugs it would be different. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [plugins] Comparison of plugin mechanisms
Hello All, Grigori Fursin wrote: Basically, we currently see 3 complementary categories of GCC plugins, depending on the nature of the extension: production, experimentation/research, and new pass integration. Each category naturally calls for slightly different API features. I am not sure of the relevance of the "new pass integration plugins" examplified by MELT. [on the other hand, I do know Grigori and I believe he thought quite a lot about plugins, which I didn't. I only implemented one particular plugin machinery = MELT, knowing well that my approach is quite peculiar both in its goals and its implementation. I never thought of MELT as a universal plugin machinery). In my view, MELT fits quite precisely in the "production plugins" definition, while indeed I expect it to be useful mostly for "experimental/research" plugins. In my view also, the "new pass integration plugin" category should not really exist, because it probably can fit inside one (or both) of the above categories. MELT definitely claims to fit into the "production plugins" slot, because MELT always was concerned by efficiency and most importantly close integration of GCC internal structures. The major point of MELT is its several idioms to fit into the *evolving* GCC internals API, and I claim that the various MELT idioms (see my GROW paper) make close integration into GCC internals possible, and perhaps even easy (for each internal "feature" of GCC, it is really easy to code the couple of MELT line to use it). Of course, MELT is mostly motivated by "experimental/research plugins", in the sense that MELT will be mostly useful for experimental and prototyping. I never thought that MELT would be useful for coding definitive optimisation passes, but it should be useful to at least prototype them. Actually, I really believe that for ordinary optimisation, any plugin machinery is not used. In other words, I tend to think that even in -O3 (or a future -O4) no plugin will be dlopen-ed by default in GCC. [by the way, I believe that this last fact is unfortunate; I would like plugins to be routinely used inside GCC, but I do know that most of the GCC community disagree.] Also, I don't understand why "production plugins" or "experimental/research plugins" could not be coded in another language than C. For sure, they could probably be coded in a suitable subdialect of C++ at least. I do like Grigori's plugin API proposal. (but again, I definitely do not claim to be a plugin theorist, only a particular plugin implementor, with MELT having specific needs & solutions.). I did not understood yet how exactly can Grigori's production plugin API be used to add e.g. one plugin pass inside the pass manager. Eg how to add one pass fooplugin_pass provided by a plugin just after the pass_inline_parameters, or another plugin pass barplugin_pass just after pass_ipa_struct_reorg? I assume such things could be possible... There is another issue which has not been discussed enough in my view. The interaction between some GCC plugins and the GGC memory manager/garbage collector. More precisely: 1. How can a plugin fooplugin.c use GTY() notation, and therefore generate a gt-fooplugin.h which is #include-d at the end of fooplugin.c? conceptually it could be quite easy: extend gengtype so that, in addition to it peculiar current use [invocation from the Makefile without program arguments] it is able to take two program arguments, the input file -here fooplugin.c- and the output file -here gt-fooplugin.h 2. Even more important, how can a plugin register static or global GTY roots and their marking routines (generated inside gt-fooplugin.h above)? The point is that after a plugin has been loaded, the ggc_collect routine should invoke some marking routines defined by the plugin! A simplistic very low level approach whould be to very simply extend ggc_collect to take an additional marking routine & data. I did provide a very small patch for that http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00431.html but very sadly it has been rejected. Has it been accepted, one could easily e.g. add a root registration in the plugin machinery and have all the dynamic roots be marked with a very simple wrapper above the proposed ggc_collect_extra_marking. I still hope that some dynamic roots (and dynamic marking routines) will be possible one day (otherwise, in my opinion, the whole plugin effort would be doomed). Regarding MELT, I believe that if a plugin facility has, in addition of Gregori's feature, the ability to insert new dynamic passes and the ability to add some extra GTY root & marking routine, I could fit MELT into that. If that happens, MELT would become somehow a "metaplugin" machinery, in the sense of a plugin which will itself load some dynamic code. In Grigori's table Side-by-side comparison of production and research/experimental plugin APIs I believe that MELT probabl
