GCC 4.3.0 Status Report (2007-08-09)

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

deadline extension for debug info project into GCC 4.3 stage3?

[Alexandre Oliva]

On Aug  9, 2007, Mark Mitchell <mark@codesourcery.com> wrote:

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

I was hoping I'd have the new debug info infrastructure, based on
annotations carried all the way from the source code, ready in time.

Even though I already have code to introduce the annotations in the
tree representation, only when generating debug information, and to
carry them over all the way to rtl var-tracking, without any changes
whatsoever to the generated code on x86_64-linux-gnu.  I have already
written (over this past weekend) some code in var-tracking to use
these annotations to generate improved debug info notes, but this last
part still needs some work.

I think it would be nice to offer this new debug info generation
machinery, at least as an option, in GCC 4.3, so I'd like to request
some more time to make it fully functional before I post the very
large patches.

Making it optional and disabled by default would make it very
non-intrusive and safe for stage3, in spite of the patch size, and
would enable a wider audience to give it a try and report problems and
opportunities for improvement.  I'm already aware of many of these,
but I'm not yet at a point in which I can compare the quality of the
generated debug info.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: deadline extension for debug info project into GCC 4.3 stage3?

[Mark Mitchell]

Alexandre Oliva wrote:

> I think it would be nice to offer this new debug info generation
> machinery, at least as an option, in GCC 4.3, so I'd like to request
> some more time to make it fully functional before I post the very
> large patches.

Thank you for letting me know.

> Making it optional and disabled by default would make it very
> non-intrusive and safe for stage3, in spite of the patch size, and
> would enable a wider audience to give it a try and report problems and
> opportunities for improvement.

That's a possibility, but I don't want to commit at this point.  We can
have a look at it when you submit it and decide.  However, in general,
introducing churn for the sake of a feature that will be off by default
isn't something that I would want to do.  The more compartmentalized you
make it, the better your chances are.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: deadline extension for debug info project into GCC 4.3 stage3?

[Alexandre Oliva]

On Sep 11, 2007, Mark Mitchell <mark@codesourcery.com> wrote:

> That's a possibility, but I don't want to commit at this point.  We can
> have a look at it when you submit it and decide.  However, in general,
> introducing churn for the sake of a feature that will be off by default
> isn't something that I would want to do.  The more compartmentalized you
> make it, the better your chances are.

It's nearly impossible to make the patch compartmentalized, but pretty
much all of the changes would be clearly disabled and no-ops unless
the flag was given in the command line.

That said, I found out there's still a long way to go before this is
actually a no-op in terms of generated code (other than debug info,
that is), as far as testsuite results, target libraries and other
ports are concerned, so I'm thinking this is very unlikely to make 4.3
:-(

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: deadline extension for debug info project into GCC 4.3 stage3?

[Richard Guenther]

On 9/26/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Sep 11, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
>
> > That's a possibility, but I don't want to commit at this point.  We can
> > have a look at it when you submit it and decide.  However, in general,
> > introducing churn for the sake of a feature that will be off by default
> > isn't something that I would want to do.  The more compartmentalized you
> > make it, the better your chances are.
>
> It's nearly impossible to make the patch compartmentalized, but pretty
> much all of the changes would be clearly disabled and no-ops unless
> the flag was given in the command line.
>
> That said, I found out there's still a long way to go before this is
> actually a no-op in terms of generated code (other than debug info,
> that is), as far as testsuite results, target libraries and other
> ports are concerned, so I'm thinking this is very unlikely to make 4.3
> :-(

Can you develop this more in the open to allow contribution, facititate further
review and make merging it to 4.4 less pain?  It looks like that if the patch
is not easy to compartmentalize then a branch would be appropriate, though
also patches would be fine.  I find myself in a situation where I would need to
start doing the same work as you (possibly).

Thanks,
Richard.

Re: deadline extension for debug info project into GCC 4.3 stage3?

[Alexandre Oliva]

On Oct  1, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> Can you develop this more in the open to allow contribution,
> facititate further review and make merging it to 4.4 less pain?

Sure!  I'm very glad you asked ;-)

I've just created the var-tracking-assignments branch, and I'll check
my pending patches into it over the course of the day.  Some of them
are also applicable to mainline, so I'll submit them as such; others
are branch-only for now, and I'll use ChangeLog.vta for them.

> I find myself in a situation where I would need to start doing the
> same work as you (possibly).

I can send you the patches in private if you'd like to get your hands
dirty right away, just let me know ;-)


Here's the patch for the web pages that I'm checking in:

--- svn.html	13 Sep 2007 02:13:37 -0300	1.61
+++ svn.html	01 Oct 2007 11:53:32 -0300	
@@ -156,6 +156,12 @@ list therefore provides only some repres
 
 <dl>
 
+  <dt>var-tracking-assignments-branch</dt>
+  <dd>This branch aims at improving debug information by annotating
+  assignments early in the compilation, and carrying over such
+  annotations throughout optimization passes and representations.
+  This branch is maintained by Alexandre Oliva.</dd>
+
   <dt><a href="projects/tree-profiling.html">tree-profiling-branch</a></dt>
   <dd>This branch is for the development of profiling heuristics
   and profile based optimizations for trees, such as profile driven inline


-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: deadline extension for debug info project into GCC 4.3 stage3?

[Richard Guenther]

On 10/1/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Oct  1, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
>
> > Can you develop this more in the open to allow contribution,
> > facititate further review and make merging it to 4.4 less pain?
>
> Sure!  I'm very glad you asked ;-)
>
> I've just created the var-tracking-assignments branch, and I'll check
> my pending patches into it over the course of the day.  Some of them
> are also applicable to mainline, so I'll submit them as such; others
> are branch-only for now, and I'll use ChangeLog.vta for them.

Thanks!

> > I find myself in a situation where I would need to start doing the
> > same work as you (possibly).
>
> I can send you the patches in private if you'd like to get your hands
> dirty right away, just let me know ;-)

No need to hurry, I'll happily wait for the patches to arrive on the branch.

Richard.

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

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.