GCC 4.3.0 Status Report (2007-08-09)
Summary --- We entered Stage 2 on July 6th. I plan to put us into Stage 3 on September 10th. At that point, we will accept only bug-fixes -- no more new features until Stage 1 for GCC 4.4. Are there any folks out there who have projects for Stage 1 or Stage 2 that they are having trouble getting reviewed? Any comments re. timing for Stage 3? Quality --- At this point, we have 194 P3-or-higher regressions open against 4.3.0: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.2&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= I have not yet triaged the many P3 bugs, so I expect that some of these will be downgraded. An interesting fact is that now about half of the 34 P1s re 4.3-only regressions. So, we have been introducing some new and exciting bugs, and we need to fix those. Do we need another 1-week stabilization period? Previous Report --- http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-08-09)
On 8/10/07 9:49 AM, Diego Novillo wrote: > Zadeck has the parloop branch patches [ ... ] Sorry, I meant Zdenek.
Re: GCC 4.3.0 Status Report (2007-08-09)
On 8/9/07 6:19 PM, Mark Mitchell wrote: > Are there any folks out there who have projects for Stage 1 or Stage 2 > that they are having trouble getting reviewed? Any comments > re. timing for Stage 3? Zadeck has the parloop branch patches, which I've been reviewing. I am not sure how many other patches are left, but at least a couple. Zdenek are the remaining patches submitted already? I have one in my review list, but I don't know if there are others. I could go over them next week.
Re: GCC 4.3.0 Status Report (2007-08-09)
Hello, > > Are there any folks out there who have projects for Stage 1 or Stage 2 > > that they are having trouble getting reviewed? Any comments > > re. timing for Stage 3? > > Zadeck has the parloop branch patches, which I've been reviewing. I am > not sure how many other patches are left, but at least a couple. Zdenek > are the remaining patches submitted already? I have one in my review > list, but I don't know if there are others. I could go over them next week. not yet, I just returned from vacation and I should send the remaining two or three patches for the parloop branch merge this week. Zdenek
Re: GCC 4.3.0 Status Report (2007-08-09)
We have a lot of patches to the ARC port, but I suppose that would not really be a problem for phase three, as the current arc port in the gcc mainline is not really useful for end users - it doesn't support any of the cores that have been released in recent years. Some patches belong logically to the arc port, but are in common files, so they have to go in sufficiently early before the release freeze to allow to verify that no other configurations are affected by typos etc; these files are: config-ml.in config.gcc doc/invoke.texi There remain two issues that require patches to the common code. Our Copyright Assignment is still not sorted out, so I will refer here to patches only by Changelog entry, without posting any actual code. There is an issue with precompiled headers that shows up specifically with the arc configuration. Some GTY data structures point to malloced strings in the arc port. 2007-05-14 J"orn Rennecke <[EMAIL PROTECTED]> Make section xmalloced: * c-pch.c (c_common_write_pch): Call pickle_in_section and unpickle_in_section. (c_common_read_pch): Call unpickle_in_section. * varasm.c (unnamed_sections): Remove GTY marker. (get_unnamed_section, get_noswitch_section): xmalloc section. (pickled_in_section): New static variable. (pickle_in_section, unpickle_in_section): New functions. * output.h (struct unnamed_section): Mark as GTY((skip)). (union section): Mark members unnamed_section and noswitch_section as GTY((skip)). (text_section, data_section, readonly_data_section): Remove GTY marker. (sdata_section, ctors_section, dtors_section, bss_section): Likewise. (sbss_section, tls_comm_section, comm_section): Likewise. (lcomm_section, bss_noswitch_section, in_section): Likewise. (pickle_in_section, unpickle_in_section): Declare. The following patch should be reworked to avoid code duplication, which will likely require patches to the frontend and middle-end: 2007-05-29 J"orn Rennecke <[EMAIL PROTECTED]> * config/arc/arc.c (arc_decl_anon_ns_mem_p): New function, copied from cp/tree.c . (arc_in_small_data_p): Use default_binds_local_p_1 and arc_decl_anon_ns_mem_p to determine if a symbol binds locally.
Re: GCC 4.3.0 Status Report (2007-08-09)
> > Summary > --- > > We entered Stage 2 on July 6th. I plan to put us into Stage 3 on > September 10th. At that point, we will accept only bug-fixes -- no > more new features until Stage 1 for GCC 4.4. > > Are there any folks out there who have projects for Stage 1 or Stage 2 > that they are having trouble getting reviewed? Any comments > re. timing for Stage 3? One thing I would like to see in is the sharing checker. The criteria of bootstrap/regtesting on primary platforms is almost met now with exception of regmove pass that I sent patch for some time ago. http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01441.html I will do re-testing now and see if some new problems has appeared. Honza
Re: GCC 4.3.0 Status Report (2007-08-09)
Jan Hubicka wrote: > One thing I would like to see in is the sharing checker. The criteria > of bootstrap/regtesting on primary platforms is almost met now with > exception of regmove pass that I sent patch for some time ago. > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01441.html > I will do re-testing now and see if some new problems has appeared. Thank you for bringing this up. I'd let to get the checker in too. But, I don't really understand the regrename.c patch. Are you saying that regrename.c is broken, and that we need to make these copies because of a real bug? Or just to make the checker happy? If the latter, have you measured the compile-time and memory usage to see what impact that has? We'd like to avoid making the compiler slower just to make the checker happy -- but, of course, it might be worth a small hit to get the checking benefit. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-08-09)
> Jan Hubicka wrote: > > > One thing I would like to see in is the sharing checker. The criteria > > of bootstrap/regtesting on primary platforms is almost met now with > > exception of regmove pass that I sent patch for some time ago. > > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01441.html > > I will do re-testing now and see if some new problems has appeared. > > Thank you for bringing this up. I'd let to get the checker in too. > But, I don't really understand the regrename.c patch. Are you saying > that regrename.c is broken, and that we need to make these copies > because of a real bug? Or just to make the checker happy? If the Introducing wrong sharing is real bug :) But I know of no testcase where it leads to ICE or produce wrong code without checker. Regrename is run late, sharing is introduced just for complex instruction patterns and not too many passes afterwards cares about sharing. The copying occurs only when nontrivial RTX expressions are matched that happens generally only in combiner patterns dealing with arithmetic and corresponding set of flags that are not terribly common, so it is sub 1% memory use growth on combine.c and PPC, 0% on i386. However I am no longer sure I fully understand why the sharing is needed at first place - regrename seems to have later mechanizm to deal with match_dup and it seems to me that it only can result in mismatch when there was invalid sharing before regrename introduced (so updating the insn caused one copy of the matched RTX to be alterned but no other copy). I am now re-testing alternate patch that simply disables the code introducing sharing in a hope that it will was just symptomatic fix for sharing issue orignally and it will simply pass now. I will know results tonight. Honza > latter, have you measured the compile-time and memory usage to see what > impact that has? We'd like to avoid making the compiler slower just to > make the checker happy -- but, of course, it might be worth a small hit > to get the checking benefit. > > Thanks, > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-08-09)
On 8/10/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Are there any folks out there who have projects for Stage 1 or Stage 2 > that they are having trouble getting reviewed? Any comments > re. timing for Stage 3? > I have many bfin port patches which have not been merged into upstream. I hope I can pushed them out by the end of the next week. Jie
Re: GCC 4.3.0 Status Report (2007-08-09)
Mark Mitchell <[EMAIL PROTECTED]> wrote on 09/08/2007 17:19:13: > > Are there any folks out there who have projects for Stage 1 or Stage 2 > that they are having trouble getting reviewed? struct-reorg + ipa-type-escape changes are awaiting for response. http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00028.html http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00024.html Olga
Re: GCC 4.3.0 Status Report (2007-08-09)
Jie Zhang wrote: On 8/10/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Are there any folks out there who have projects for Stage 1 or Stage 2 that they are having trouble getting reviewed? Any comments re. timing for Stage 3? I have many bfin port patches which have not been merged into upstream. I hope I can pushed them out by the end of the next week. I have sent out all my patches (11). 3 of them have been reviewed and committed. Others are being reviewed. I have no access to computer this weekend. I'll be back next Monday or Tuesday. Jie
