GCC 4.5 Status Report (2009-09-19)

GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

Status
======

The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
Stage 3 follows with only bugfixes and no new features allowed. 
Stage 3 will end Nov 30th.

Since the last status report we have merged the VTA branch and pieces
of the LTO branch.  The named address-spaces changes are still pending
review but I expect it to be merged before the end of Stage 1.
The rest of the LTO branch will be merged last, which practically
means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
be frozen for the LTO merge and I'll announce Stage 3 once the merge
is completed.

There are still new ports pending review and approval.  As usual
new ports can be accepted also during Stage 3.

We've been accumulating quite a number of P1 bugs.  Entering Stage 3
should allow to improve considerably here in a short time.

Quality Data
============

Priority	  #	Change from Last Report
--------	---	-----------------------
P1		 22     + 6
P2		111 	+ 7
P3		  6	+ 6
--------	---	-----------------------
Total		139	+19

Previous Report
===============

http://gcc.gnu.org/ml/gcc/2009-08/msg00427.html

The next report will be sent by me announcing Stage 3 begin.

-- 
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: GCC 4.5 Status Report (2009-09-19)

[Steven Bosscher]

On Sat, Sep 19, 2009 at 10:57 PM, Richard Guenther <rguenther@suse.de> wrote:
> Since the last status report we have merged the VTA branch and pieces
> of the LTO branch.  The named address-spaces changes are still pending
> review but I expect it to be merged before the end of Stage 1.
> The rest of the LTO branch will be merged last, which practically
> means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> be frozen for the LTO merge and I'll announce Stage 3 once the merge
> is completed.

Is there a set of release criteria for all these major new features?
For example:

* testsuite for C/C++/Fortran should pass with LTO

* idem with WHOPR?

* GDB test suite should pass with -O1

* SPEC should pass with graphite

* ...


Also, IMHO a new requirement should be added for merging big new
features: Update changes.html.  As usual for the last, say, 4
releases, most of the interesting new features are not yet described
in the changes.html for the upcoming release (see
http://gcc.gnu.org/gcc-4.5/changes.html).

Ciao!
Steven

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1658 bytes --]

On Sun, 20 Sep 2009, Steven Bosscher wrote:

> On Sat, Sep 19, 2009 at 10:57 PM, Richard Guenther <rguenther@suse.de> wrote:
> > Since the last status report we have merged the VTA branch and pieces
> > of the LTO branch.  The named address-spaces changes are still pending
> > review but I expect it to be merged before the end of Stage 1.
> > The rest of the LTO branch will be merged last, which practically
> > means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> > be frozen for the LTO merge and I'll announce Stage 3 once the merge
> > is completed.
> 
> Is there a set of release criteria for all these major new features?
> For example:
> 
> * testsuite for C/C++/Fortran should pass with LTO
> * idem with WHOPR?

Worthwhile goals.  It mostly does.

> * GDB test suite should pass with -O1

Which GDB version?

> * SPEC should pass with graphite
> 
> * ...

There will be bugs in new features, but not merging them will not
make you know them.  The premise is of course that a new feature
is usable within documented constraints.

> Also, IMHO a new requirement should be added for merging big new
> features: Update changes.html.

Yes.  Well, updating changes.html before the release.  Note that
changes.html is for user visible changes - that may or may not apply
for VTA (we don't document every new command-line flag in changes.html).

> As usual for the last, say, 4
> releases, most of the interesting new features are not yet described
> in the changes.html for the upcoming release (see
> http://gcc.gnu.org/gcc-4.5/changes.html).

Bugs for omissions are certainly welcome, likewise patches to fix them.

Thanks,
Richard.

Re: GCC 4.5 Status Report (2009-09-19)

[Jack Howarth]

On Sat, Sep 19, 2009 at 10:57:38PM +0200, Richard Guenther wrote:
> 
> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.
> 

Richard,
   Will the graphite code be under strict stage 3 rules or will it
have more leeway under stage 3? We still aren't seeing uniform code
improvements from graphite in benchmarks yet and it would be a shame
to postpone that until gcc 4.6.
             Jack

Re: GCC 4.5 Status Report (2009-09-19)

[Geert Bosch]

On Sep 19, 2009, at 18:02, Steven Bosscher wrote:
> * GDB test suite should pass with -O1

Apparently, the current GDB test suite can only work at -O0,
because code reorganization messes up the scripting.

   -Geert

Re: GCC 4.5 Status Report (2009-09-19)

[Dave Korn]

Richard Guenther wrote:

> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> Stage 3 follows with only bugfixes and no new features allowed. 
> Stage 3 will end Nov 30th.

  I don't think this is the best time to do that.  Trunk's been broken most of
last week and will probably not be buildable for at least several days yet, so
a big chunk of that warning period is going to be useless to many people.

> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.

  So aren't we now likely to lose the first few days of what little remains of
stage 1 waiting for trunk to start working again, then have a mad rush of
people falling all over each other to get their new features in in the last
couple of days?  One of which will inevitably break trunk again and block all
the others and then stage 1 will be over and it'll all be too late?

  Ten days isn't even that much warning in the first place; it's less time
than you'd generally let elapse before pinging a patch.  Can I at least raise
the suggestion that a plan that might work well would be for us to go slush
for however long - less than a week, I'd suppose - it takes us to get trunk
really properly stable, and then push back the end of stage 1 by that amount?

    cheers,
      DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Sun, 20 Sep 2009, Dave Korn wrote:

> Richard Guenther wrote:
> 
> > The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> > Stage 3 follows with only bugfixes and no new features allowed. 
> > Stage 3 will end Nov 30th.

I'll answer your and Jacks question together.

>   I don't think this is the best time to do that.  Trunk's been broken most of
> last week and will probably not be buildable for at least several days yet, so
> a big chunk of that warning period is going to be useless to many people.

The effective useless period is extended by not including the 2-3 days
necessary for the LTO merge in Stage 1.

> > We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> > should allow to improve considerably here in a short time.
> 
>   So aren't we now likely to lose the first few days of what little remains of
> stage 1 waiting for trunk to start working again, then have a mad rush of
> people falling all over each other to get their new features in in the last
> couple of days?  One of which will inevitably break trunk again and block all
> the others and then stage 1 will be over and it'll all be too late?

I am not aware of any big patches that are still pending.  Coming up
with new yet unknown things now wouldn't be a good timing anyway.

>   Ten days isn't even that much warning in the first place; it's less time
> than you'd generally let elapse before pinging a patch.  Can I at least raise
> the suggestion that a plan that might work well would be for us to go slush
> for however long - less than a week, I'd suppose - it takes us to get trunk
> really properly stable, and then push back the end of stage 1 by that amount?

Note that Stage 3 isn't that strict as it may sound.  Maintainers have
quite amount of flexibility deciding what is considered a bug and thus
a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
fixes).  This includes obviously Graphite and LTO as well as target
specific changes.

What you won't see in Stage 3 is rewrites of infrastructure or adding of
new optimization passes.

Note that we have been in Stage 1 for about six month now which is
IMHO enough (and unsurprisinlgy matches the length of Stage 1 of GCC 4.4).

Richard.

Re: GCC 4.5 Status Report (2009-09-19)

[Dave Korn]

Richard Guenther wrote:

> Note that Stage 3 isn't that strict as it may sound.  Maintainers have
> quite amount of flexibility deciding what is considered a bug and thus
> a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
> fixes).  This includes obviously Graphite and LTO as well as target
> specific changes.
> 
> What you won't see in Stage 3 is rewrites of infrastructure or adding of
> new optimization passes.

  Thanks Richard, that's pretty reassuring.

  BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?  It
sounds a lot like the way that's still described on develop.html.

    cheers,
      DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Sun, 20 Sep 2009, Dave Korn wrote:

> Richard Guenther wrote:
> 
> > Note that Stage 3 isn't that strict as it may sound.  Maintainers have
> > quite amount of flexibility deciding what is considered a bug and thus
> > a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
> > fixes).  This includes obviously Graphite and LTO as well as target
> > specific changes.
> > 
> > What you won't see in Stage 3 is rewrites of infrastructure or adding of
> > new optimization passes.
> 
>   Thanks Richard, that's pretty reassuring.
> 
>   BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?  It
> sounds a lot like the way that's still described on develop.html.

Because "New functionality may not be introduced during this period." is
still true for this stage 3 and "support for a new language construct 
might be added in a front-end" is also not wanted.

Richard.

Re: GCC 4.5 Status Report (2009-09-19)

[Dave Korn]

Richard Guenther wrote:
> On Sun, 20 Sep 2009, Dave Korn wrote:

>>   BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?  It
>> sounds a lot like the way that's still described on develop.html.
> 
> Because "New functionality may not be introduced during this period." is
> still true for this stage 3 and "support for a new language construct 
> might be added in a front-end" is also not wanted.

  Ah, thanks.  I missed the discussion when stage 2 fell out of use, it would
be nice if someone who was there at the time added a note to develop.html - is
it an ad-hoc thing that we've just done for a couple of releases because it
made sense at the time or was there an SC decision to permanently modify the
development plan?

    cheers,
      DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Cary Coutant]

>>   So aren't we now likely to lose the first few days of what little remains of
>> stage 1 waiting for trunk to start working again, then have a mad rush of
>> people falling all over each other to get their new features in in the last
>> couple of days?  One of which will inevitably break trunk again and block all
>> the others and then stage 1 will be over and it'll all be too late?
>
> I am not aware of any big patches that are still pending.  Coming up
> with new yet unknown things now wouldn't be a good timing anyway.

I was hoping to get the dwarf4 branch merged into trunk during stage
1. While it's not a small patch, it's also not really that intrusive
in that it consists mostly of new code that runs only with the
-gdwarf-4 option. I've been testing it on a lot of big code bases for
the last few months, and haven't found any new bugs for a more than a
month now, so I think it's ready.

I'll work on merging top-of-trunk into the branch early this week and
then send a patch to merge back into the trunk.

-cary

Re: GCC 4.5 Status Report (2009-09-19)

[Jack Howarth]

On Mon, Sep 21, 2009 at 11:23:11AM -0700, Cary Coutant wrote:
> >>   So aren't we now likely to lose the first few days of what little remains of
> >> stage 1 waiting for trunk to start working again, then have a mad rush of
> >> people falling all over each other to get their new features in in the last
> >> couple of days?  One of which will inevitably break trunk again and block all
> >> the others and then stage 1 will be over and it'll all be too late?
> >
> > I am not aware of any big patches that are still pending.  Coming up
> > with new yet unknown things now wouldn't be a good timing anyway.
> 
> I was hoping to get the dwarf4 branch merged into trunk during stage
> 1. While it's not a small patch, it's also not really that intrusive
> in that it consists mostly of new code that runs only with the
> -gdwarf-4 option. I've been testing it on a lot of big code bases for
> the last few months, and haven't found any new bugs for a more than a
> month now, so I think it's ready.
> 
> I'll work on merging top-of-trunk into the branch early this week and
> then send a patch to merge back into the trunk.
> 
> -cary
> 

Cary,
   Are you saying that current gcc trunk should require -gdwarf-4
to issue dwarf4 commands? I ask because r151815...

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html

causes dwarf4 by default. Is there a consistent policy on this?
Currently in PR41405, there is a proposal for a -gstrict-dwarf
option which I guess should be expanded to cover your patch if
gcc 4.5 will be defaulting to -gdwarf-4 being enabled.
                   Jack

Re: GCC 4.5 Status Report (2009-09-19)

[Cary Coutant]

>   Are you saying that current gcc trunk should require -gdwarf-4
> to issue dwarf4 commands? I ask because r151815...
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html
>
> causes dwarf4 by default. Is there a consistent policy on this?
> Currently in PR41405, there is a proposal for a -gstrict-dwarf
> option which I guess should be expanded to cover your patch if
> gcc 4.5 will be defaulting to -gdwarf-4 being enabled.

That patch actually enables the use of certain DWARF extensions
(DW_OP_stack_value and DW_OP_implicit_value) from the DWARF-4 spec
while still generating nominal DWARF-2. Since DWARF was designed for
extensibility, this isn't a problem for these extensions, as older
DWARF readers will simply ignore the location expressions that use the
extensions -- which produces the same behavior as DWARF-2 without
those extensions. Because the behavior with an older consumer is no
worse than the behavior without the extension, it's perfectly
reasonable to use these extensions without any gating option.

There are a couple of new things in the DWARF-4 spec that are not
completely backward compatible with DWARF-2, but none of those are
implemented in gcc yet. In fact, my dwarf4 branch still generates
nominal DWARF-2 output, while using the extensions from DWARF-4 to
allow the separation of type info into separate COMDAT sections. I
gate the new behavior on the -gdwarf-4 option, however, since the use
of this extension with an older consumer would represent a loss of
functionality -- the older consumer would not see any of the type
information that was placed in COMDAT sections. Thus, my changes won't
be enabled by default, so they won't need to be affected by the
-gstrict-dwarf option.

I think gcc with -gdwarf-4 can (and should) continue to mark the DWARF
output as version 2 until it starts taking advantage of some of the
new FORMs (which old consumers will not know how to skip and ignore),
the new line number table header format, and the new frame section
format. And it shouldn't start taking advantage of those things until
gdb support for those features is available.

-cary

Re: GCC 4.5 Status Report (2009-09-19)

[Cary Coutant]

> extensibility, this isn't a problem for these extensions, as older
> DWARF readers will simply ignore the location expressions that use the
> extensions -- which produces the same behavior as DWARF-2 without
> those extensions.

I said "will simply ignore" when I guess I should have said "should
simply ignore". Obviously, the whole point of the -gstrict-dwarf
option is to deal with certain tools that don't simply ignore the
extensions.

-cary

Re: GCC 4.5 Status Report (2009-09-19)

[Jason Merrill]

On 09/20/2009 08:07 AM, Dave Korn wrote:
> Richard Guenther wrote:
>> On Sun, 20 Sep 2009, Dave Korn wrote:
>
>>>    BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?  It
>>> sounds a lot like the way that's still described on develop.html.
>>
>> Because "New functionality may not be introduced during this period." is
>> still true for this stage 3 and "support for a new language construct
>> might be added in a front-end" is also not wanted.
>
> Ah, thanks.  I missed the discussion when stage 2 fell out of use

As did I.  I've been figuring that a couple of C++0x bits (lambdas, 
delegating constructors) could go in during stage 2; but if there's no 
stage 2 I guess I'll go ahead and merge the lambda branch during stage 1 
rather than try to nail down all the corner cases first.

Jason

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Thu, 24 Sep 2009, Jason Merrill wrote:

> On 09/20/2009 08:07 AM, Dave Korn wrote:
> > Richard Guenther wrote:
> > > On Sun, 20 Sep 2009, Dave Korn wrote:
> > 
> > > >    BTW, why don't we call this more-flexible-stage-3 "stage 2" any more?
> > > > It
> > > > sounds a lot like the way that's still described on develop.html.
> > > 
> > > Because "New functionality may not be introduced during this period." is
> > > still true for this stage 3 and "support for a new language construct
> > > might be added in a front-end" is also not wanted.
> > 
> > Ah, thanks.  I missed the discussion when stage 2 fell out of use
> 
> As did I.  I've been figuring that a couple of C++0x bits (lambdas, delegating
> constructors) could go in during stage 2; but if there's no stage 2 I guess
> I'll go ahead and merge the lambda branch during stage 1 rather than try to
> nail down all the corner cases first.

That is what I would indeed prefer.  Stage 3 is ok for general bugfixes,
which includes nailing down corner cases.

Thanks,
Richard.

Re: GCC 4.5 Status Report (2009-09-19)

[Sriraman Tallam]

Hi,

      I have a zero-extension elimination patch that has been reviewed and needs
one minor fix before it is ready for submission. I can get this in by Thursday,
October 1st. Would it be alright to submit this patch then ?

Thanks,
-Sriraman.


On Sat, Sep 19, 2009 at 1:57 PM, Richard Guenther <rguenther@suse.de> wrote:
>
> Status
> ======
>
> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> Stage 3 follows with only bugfixes and no new features allowed.
> Stage 3 will end Nov 30th.
>
> Since the last status report we have merged the VTA branch and pieces
> of the LTO branch.  The named address-spaces changes are still pending
> review but I expect it to be merged before the end of Stage 1.
> The rest of the LTO branch will be merged last, which practically
> means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> be frozen for the LTO merge and I'll announce Stage 3 once the merge
> is completed.
>
> There are still new ports pending review and approval.  As usual
> new ports can be accepted also during Stage 3.
>
> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.
>
> Quality Data
> ============
>
> Priority          #     Change from Last Report
> --------        ---     -----------------------
> P1               22     + 6
> P2              111     + 7
> P3                6     + 6
> --------        ---     -----------------------
> Total           139     +19
>
> Previous Report
> ===============
>
> http://gcc.gnu.org/ml/gcc/2009-08/msg00427.html
>
> The next report will be sent by me announcing Stage 3 begin.
>
> --
> Richard Guenther <rguenther@suse.de>
> Novell / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
>

Re: GCC 4.5 Status Report (2009-09-19)

[Dave Korn]

Richard Guenther wrote:
> Status
> ======
> 
> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.

  Richard, I've got a patch for adding what I think (but may be wrong) counts
as a new feature - shared library libstdc++ as DLLs on windows platforms - and
it's been stuck in review limbo for two and a half months now, during which
time I have been repeatedly updating it, retesting it, and even fixed a couple
of minor bugs that cropped up in that time:

refs:   The original series of patches at
   [0/4]  http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01042.html
   [1/4]  http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01044.html
   [2/4]  http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01046.html
   [3/4]  http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01047.html
   [4/4]  http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01048.html
  and the various tweaked and updated respins at
          http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01631.html
          http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00877.html
          http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01570.html
          http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00209.html
          http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00500.html
          http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01963.html
  and test results at
          http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg01813.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg01814.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg03258.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00291.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00292.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00644.html
          http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01450.html

  We have ~48 hours left for stage 1 and I can't be confident of getting it
reviewed in the remaining time, so I'd like to make a special request: can
you, as RM, please say that this is OK in principle and that if I can get v3
approval (it already has all other necessary approvals) I can check it in
during stage 3 before we branch?

    cheers,
      DaveK

Re: GCC 4.5 Status Report (2009-09-19)

[Gerald Pfeifer]

On Tue, 29 Sep 2009, Dave Korn wrote:
> We have ~48 hours left for stage 1 and I can't be confident of getting 
> it reviewed in the remaining time, so I'd like to make a special 
> request: can you, as RM, please say that this is OK in principle and 
> that if I can get v3 approval (it already has all other necessary 
> approvals) I can check it in during stage 3 before we branch?

Historically I think we have been flexible for patches that have been
submitted during stage 1.

Now, submitting a one liner as your first attempt at a new pass today
and then claiming the rest are just fixes, would be a stretch :-), but
for a patch like yours it does not seem unreasonable.

Gerald

Re: GCC 4.5 Status Report (2009-09-19)

[Richard Guenther]

On Wed, 30 Sep 2009, Gerald Pfeifer wrote:

> On Tue, 29 Sep 2009, Dave Korn wrote:
> > We have ~48 hours left for stage 1 and I can't be confident of getting 
> > it reviewed in the remaining time, so I'd like to make a special 
> > request: can you, as RM, please say that this is OK in principle and 
> > that if I can get v3 approval (it already has all other necessary 
> > approvals) I can check it in during stage 3 before we branch?
> 
> Historically I think we have been flexible for patches that have been
> submitted during stage 1.
> 
> Now, submitting a one liner as your first attempt at a new pass today
> and then claiming the rest are just fixes, would be a stretch :-), but
> for a patch like yours it does not seem unreasonable.

Just to followup once and answer all the multiple requests that have
been (and will be) come up - during stage 3 it is up to the respective
maintainers to decide what is considered a bugfix and whether to allow
changes to go in that were submitted during stage 1.  The release
managers trust the maintainers to make stage 3 a success - which means
mainly fixing fallout from stage 1 or to complete features that have
been checked in during stage 1.

Thanks,
Richard.

Re: GCC 4.5 Status Report (2009-09-19)

[Jack Howarth]

On Wed, Sep 30, 2009 at 10:49:40AM +0200, Richard Guenther wrote:
> > 
> > Now, submitting a one liner as your first attempt@a new pass today
> > and then claiming the rest are just fixes, would be a stretch :-), but
> > for a patch like yours it does not seem unreasonable.
> 
> Just to followup once and answer all the multiple requests that have
> been (and will be) come up - during stage 3 it is up to the respective
> maintainers to decide what is considered a bugfix and whether to allow
> changes to go in that were submitted during stage 1.  The release
> managers trust the maintainers to make stage 3 a success - which means
> mainly fixing fallout from stage 1 or to complete features that have
> been checked in during stage 1.
> 
> Thanks,
> Richard.
> 

Richard,
   Is it safe to assume that with the LTO patches currently
unreviewed, the Oct. 1st deadline for stage 1 will be pushed
back? I ask because Iain is still working on the final patch
to solve PR39888 for darwin. If we in fact miss the transition
to stage 1, can this patch still go into gcc 4.5 since it is
target specific? Allowing it in would have the advantage of
setting the stage for reinstalling...

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01259.html

into gcc 4.5 without breaking darwin (since we could
just default on -muse-shared-libgcc-ext for that platform).
Thanks in advance for any clarifications as I am really
hoping some form of...

http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657

can make it into gcc 4.5.
                  Jack

Re: GCC 4.5 Status Report (2009-09-19)

[Neil Vachharajani]

Hi Richard,

I have several patches that I've emailed to gcc-patches (some a few
days ago, some a bit longer).  They are still pending code review.
Will this still be able to make it into gcc 4.5?  The list of patches
is as follows:

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01170.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01590.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02119.html

Thanks,
Neil

On Sat, Sep 19, 2009 at 1:57 PM, Richard Guenther <rguenther@suse.de> wrote:
>
> Status
> ======
>
> The trunk is in Stage 1.  Stage 1 will end on Sep 30th.  After Stage 1
> Stage 3 follows with only bugfixes and no new features allowed.
> Stage 3 will end Nov 30th.
>
> Since the last status report we have merged the VTA branch and pieces
> of the LTO branch.  The named address-spaces changes are still pending
> review but I expect it to be merged before the end of Stage 1.
> The rest of the LTO branch will be merged last, which practically
> means after Stage 1 is over.  Thus, starting Oct 1st the trunk will
> be frozen for the LTO merge and I'll announce Stage 3 once the merge
> is completed.
>
> There are still new ports pending review and approval.  As usual
> new ports can be accepted also during Stage 3.
>
> We've been accumulating quite a number of P1 bugs.  Entering Stage 3
> should allow to improve considerably here in a short time.
>
> Quality Data
> ============
>
> Priority          #     Change from Last Report
> --------        ---     -----------------------
> P1               22     + 6
> P2              111     + 7
> P3                6     + 6
> --------        ---     -----------------------
> Total           139     +19
>
> Previous Report
> ===============
>
> http://gcc.gnu.org/ml/gcc/2009-08/msg00427.html
>
> The next report will be sent by me announcing Stage 3 begin.
>
> --
> Richard Guenther <rguenther@suse.de>
> Novell / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
>



-- 
Neil Vachharajani
Google
650-214-1804