This page is not maintained by anyone at the moment. More current news can be found in GCC news and announcements. Everybody is invited to contribute. Just one thing: please, always provide links to the original discussion in the mailing list archives.
Week 11 (March 14th 2005)
Kazu Hirata submitted an additional ridiculous number of fold cleanups. See http://gcc.gnu.org/ml/gcc-patches/2005-03/authors.html
Week 10 (March 7th 2005)
Andrew Pinski merged in an improve phi optimization pass http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00548.html
Structure aliasing part 1 was merged in by Daniel Berlin. http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00896.html
- Kazu Hirata performed some fold cleanups.
Week 9 (Feb 28th 2005)
Some 4.1 projects have started to merge. See GCC_4.1_Projects for the list of outstanding projects.
Daniel Berlin merged in a patch to perform code sinking and store sinking. http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01834.html
- Joseph S. Myers merged in a new C parser.
Some work on the autovect branch to begin support for reductions was committed http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01407.html
Week 8 (Feb, 21th 2005)
Mark Mitchell created the gcc 4.0 release branch, set up a list of projects for gcc 4.1 GCC_4.1_Projects and a timetable for these projects http://gcc.gnu.org/ml/gcc/2005-02/msg01008.html
Joseph S. Myers intends to commit the new C parser to mainline (now 4.1) http://gcc.gnu.org/ml/gcc/2005-02/msg01009.html
- Steven Bosscher announced he that he will merge mainline to the GOMP branch when the parser is in
Week 7 (Feb, 14th 2005)
Week 6 (Feb, 7th 2005)
Daniel Berlin prepared a GCC SVN repository for testing purposes. All developers are encouraged to experiment with it!
Joseph S. Myers exposed a first problem with the SVN repository, related to getting the log of a deleted file in a possibly deleted directory. Also, he found out that the whole log of a file appears to be sent across the network in uncompressed form.
Daniel Berlin reported that he is working to make "svn blame" faster. This is a very good news since a svn blame (equivalent of cvs annotate currently takes forever (like, hours) on the GCC test repository.
Steven Bosscher raised some concerns about the exact duties of the Release Manager. The concerns were originated from Mark's planning for GCC 4.1, where he asked to be sent a description of the projects that were planned for GCC 4.1, so that they could be evaluated for inclusion. In Steven's words:
- _I respectfully disagree with your description of your role as RM: "to make decisions that advance the overall state of the compiler". It is not your decision to make, or the small group you value. [...] Those decisions should be made in the Steering Committee. I believe that you, as the RM, should not leave an impression that you make the decisions at your discretion. That is not how it is supposed to be IMHO._
Mark replied:
- _Obviously, I'm not some kind of uber-despot for GCC. I don't even *want* to be that, and I'd certainly not get away with actually trying to be that. The SC has given me some authority to control certain aspects of things, and I think that clearly includes coordinating the inclusion of major features so as to avoid conflicts between patches being merged._
Week 5 (Jan, 31st 2005)
Daniel Berlin proposed to switch the GCC repository to use Subversion as a VCS, and volunteered to do the actual work (he also made GCC switch from GNATS to Bugzilla, and setup this very Wiki). He postulated that Subversion is the only viable option at this time because:
- Subversion is available on the platforms we need, and most of the tools we use with CVS support Subversion already (like viewcvs).
- Subversion is similar to CVS, which means that developers will not have to dramatically change their working habits.
- Subversion fixes the main problem GCC has with CVS right now: slowness on the branches. Right now, a simple operation like tagging all the files on a branch can take more than two hours to complete...
Mark Mitchell said that he has no objection with respect to switching to Subversion. Thorsten Glaser proposed to investigate on the problems Mono encountered in the switch-over, but the general feeling is that some minor EOL issues (during the conversion process only) and slower "svn annotate" are absolutely not show-stoppers for GCC.
- There was a hardware failure in the computer running gcc.gnu.org. Looks like nothing was lost thanks to the backups, but the site was down for a few days. Read about it on the front page.
Mark posted a new status report on the 4.0 release. It looks like things are in good shape now (only 103 regressions open in Bugzilla) and the release branch will finally be made on February 24th; the expected release date for GCC 4.0 is April 15th. In the mail, Mark also starts planning for GCC 4.1.
Week 4 (Jan, 24th 2005)
- Fixes and improvements were made to PRE, the vectorizer, and induction variable optimizations
- Arend Bayer posted a patch to speedup CSE by 5%, then posted another one to reduce its memory usage (which sped up the compiler 1% as well)
Remy Martin asked to integrate more options from the Apple GCC compiler (for OS X) into the official FSF GCC. Among the others, Mike Stump (of Apple) answered:
- _Apple does not want to keep any compiler changes to ourselves. It is in our interest to have as many of our changes as possible get into the mainline gcc tree. [...] If there are any Apple local patches that you would like to see in mainline, please let us, and the gcc community as a whole, know about them. I would love to see mainline gcc be useful for building OS X applications. We aren't there yet, but we're a lot closer than we were a couple years ago._
Uros Bizjak posted the results of a benchmark of Povray for both GCC 4.0 andGCC 3.4, that shows the improvement achieved by RTH and his work on MMX/SSE code generation.