Re: GCC 4.3.0 Status Report (2007-08-09)

Re: GCC 4.3.0 Status Report (2007-08-09)

[Joern Rennecke]

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  <joern.rennecke@arc.com>

	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  <joern.rennecke@arc.com>

        * 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)

[Olga Golovanevsky]

Mark Mitchell <mark@codesourcery.com> 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

GCC 4.3.0 Status Report (2007-08-09)

[Mark Mitchell]

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
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-08-09)

[Diego Novillo]

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)

[Diego Novillo]

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)

[Zdenek Dvorak]

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)

[Jan Hubicka]

> 
> 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)

[Mark Mitchell]

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
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-08-09)

[Jan Hubicka]

> 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
> mark@codesourcery.com
> (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-08-09)

[Jie Zhang]

On 8/10/07, Mark Mitchell <mark@codesourcery.com> 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)

[Jie Zhang]

Jie Zhang wrote:
> On 8/10/07, Mark Mitchell <mark@codesourcery.com> 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