Release Schedule

Release Schedule

[Jim Blomo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Would it be possible to update the development schedule to reflect the current 
state of gcc?  Like many people, I am interested in when planned releases are 
going to take place. While I realise that these dates are not set in stone, 
it would be nice to know what the developers are aiming for without reading 
the mailing list.  Specificly, http://gcc.gnu.org/develop.html#calendar could 
use some updating, as 3.1 obviously has not been released yet.  The following 
release dates will probably need some adjustment too?  Thanks for all the 
hard work you put into the site and development.

- -- 
Jim Blomo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjzI/wgACgkQUlS7JsvyVRI4LgCgsJQFYeVYmHASaLnekRPokTtN
RSIAn3YlAMgSSAdY8pZVhljkVMeqMT2P
=QXbX
-----END PGP SIGNATURE-----

Re: Release schedule

[Stan Shebs]

Joe Buck wrote:

>Steven Bosscher wrote:
>
>>FWIW I am all *against* freezing dev branches. GCC developers are
>>volunteers, and taking away their fun projects is a bad thing.
>>
>>Still I also think there are too many development projects right now, and I
>>also believe that it would be good to plan when these major improvements
>>should be finished, no matter how hard that may be in a project that depends
>>on the time of volunteers.
>>
>
>I think it's reasonable to *request* folks working on fun projects to
>consider turning their attention back to trying to stabilize the release
>at critical times in the development cycle, but that it's fruitless to try
>to bludgeon them into doing so.
>
I agree; the current system of restricting the trunk probably forces
things about as much as one can get away with.  The current system
*does* make a difference; I can tell my mgmt that the compiler is in
a bugfixing phase and they're OK with me working on bugs in FSF GCC
during that phase.

I also note that some of those "fun" projects are actually development
work being paid for by various people, and the funders would justifiably
feel cheated if they found that they were paying for release stabilization
instead.  GCC release activity must always come after contractual
obligations.

Thinking about the problem, one thing I see is that there is not a lot
of visibility into PRs that might be especially relevant to particular
communities.  For instance, Apple has multiple people that could be put
onto PRs that are known to cause bad codegen for Darwin apps, but for
the PRs that are about compiling Linux kernels on ia64, it's harder to
justify giving those as much priority.

How about a sort of bulletin board where some people post interest
in particular kinds of bugs, and where either the original PR
reporter or somebody else knowledgeable could say, "you should be
interested in this one because it affects all PowerPC, or all pic
code".

Stan

>

Re: Release schedule

[Joe Buck]

Steven Bosscher wrote:
> FWIW I am all *against* freezing dev branches. GCC developers are
> volunteers, and taking away their fun projects is a bad thing.
> 
> Still I also think there are too many development projects right now, and I
> also believe that it would be good to plan when these major improvements
> should be finished, no matter how hard that may be in a project that depends
> on the time of volunteers.

I think it's reasonable to *request* folks working on fun projects to
consider turning their attention back to trying to stabilize the release
at critical times in the development cycle, but that it's fruitless to try
to bludgeon them into doing so.

Re: Release schedule

[Pop Sébastian]

On Mon, Sep 30, 2002 at 11:46:28PM +0200, S. Bosscher wrote:
> On Saturday, September 28, 2002, at 02:21 PM, Steven Bosscher wrote:
> >>> 	Because of the overlap between releases and development, GCC
> >>> developers are forced to make a choice
> >>
> >> Yes, and closing development branches in the weeks before branching
> >> would "help" them make the choice ;-)
> >
> > Or it would drive them back underground, where they were in the past.
> 
> yeah yeah I know, this was meant to be sarcasm, note the smiley...
> 
> FWIW I am all *against* freezing dev branches. GCC developers are
> volunteers, and taking away their fun projects is a bad thing.
> 
Agree, we're not paid for doing this, thus we can spend time on what 
_we_ consider to be of interest.
Even if you close our branches you'll not get more bug fixes...

> Still I also think there are too many development projects right now, and I
> also believe that it would be good to plan when these major improvements
> should be finished, no matter how hard that may be in a project that depends
> on the time of volunteers.
> 
Why not having a per major improvment release instead of the current 
strict release schedule?  

We don't sell our product, so I don't see why we should be constrained 
by a strict schedule release.

If you want to have a strict schedule on the mainline, then you have to allow 
schedule-free development on branches.


Sebastian

RE: Release schedule

[S. Bosscher]

On Saturday, September 28, 2002, at 02:21 PM, Steven Bosscher wrote:
>>> 	Because of the overlap between releases and development, GCC
>>> developers are forced to make a choice
>>
>> Yes, and closing development branches in the weeks before branching
>> would "help" them make the choice ;-)
>
> Or it would drive them back underground, where they were in the past.

yeah yeah I know, this was meant to be sarcasm, note the smiley...

FWIW I am all *against* freezing dev branches. GCC developers are
volunteers, and taking away their fun projects is a bad thing.

Still I also think there are too many development projects right now, and I
also believe that it would be good to plan when these major improvements
should be finished, no matter how hard that may be in a project that depends
on the time of volunteers.

Greetz
Steven

Re: Release schedule

[Mike Stump]

On Saturday, September 28, 2002, at 02:21 PM, Steven Bosscher wrote:
>> 	Because of the overlap between releases and development, GCC
>> developers are forced to make a choice
>
> Yes, and closing development branches in the weeks before branching
> would "help" them make the choice ;-)

Or it would drive them back underground, where they were in the past.

Re: Release schedule

[Andrew Pinski]

There is another regression report as other/8091, as if you install a 
native version of gcc, you do not get gcc.

Thanks,
Andrew Pinski


On Monday, Sep 30, 2002, at 06:41 US/Pacific, Richard Zidlicky wrote:

> On Wed, Sep 25, 2002 at 11:28:50AM -0700, Mark Mitchell wrote:
>> I have been remiss in making announcements about the release schedule.
>>
>> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
>> October 1st, with subsequent changes coming only with my approval.  
>> Are
>> there known regressions that we need to fix for GCC 3.2.1?  If so, 
>> please
>> mail PR numbers to me.
>
> PR 7872  problem with gen_lowpart on linux-m68k, prevents build of 
> glibc-2.2.5
> PR 7871  problem with global register variables
>
> Both are regressions from 3.0.3
>
> Richard
>
>
>

Re: Release schedule

[Richard Zidlicky]

On Wed, Sep 25, 2002 at 11:28:50AM -0700, Mark Mitchell wrote:
> I have been remiss in making announcements about the release schedule.
> 
> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
> October 1st, with subsequent changes coming only with my approval.  Are
> there known regressions that we need to fix for GCC 3.2.1?  If so, please
> mail PR numbers to me.

PR 7872  problem with gen_lowpart on linux-m68k, prevents build of glibc-2.2.5
PR 7871  problem with global register variables

Both are regressions from 3.0.3

Richard

Re: Release schedule

[Michael Matz]

Hi,

On Sun, 29 Sep 2002, Richard Henderson wrote:

> > http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00044.html
>
> I have a suspicion that it interacts badly with code that actually
> uses mmx patterns,

That's correct.  But it's not worse then without that patch, where the
short living spill regs were only from the GENERAL_REGS class, so even
floats needed to be reloaded.  Now it's just mmx regs which are penalized.

> but as -fnew-ra isn't the default, and you've a
> proper solution on the way, this is ok.

Fine.  Will rebootstrap/test and apply then.


Ciao,
Michael.

Re: Release schedule

[Richard Henderson]

On Wed, Sep 25, 2002 at 03:11:13PM -0400, David Edelsohn wrote:
> GCSE fix (Mips regression fix):
> http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01557.html

Ok.

> SSE_MATH macros:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01345.html

Ok.


r~

Re: Release schedule

[Richard Henderson]

On Wed, Sep 25, 2002 at 08:55:28PM +0200, Michael Matz wrote:
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00044.html

I have a suspicion that it interacts badly with code that actually
uses mmx patterns, but as -fnew-ra isn't the default, and you've a
proper solution on the way, this is ok.



r~

Re: Release schedule

[David Edelsohn]

>>>>> Steven Bosscher writes:

Steven> Yes, and closing development branches in the weeks before branching
Steven> would "help" them make the choice ;-)

	GCC developers are volunteers, not employees.  GCC has limited
developers resources because it has done a very good job of driving away
developers without your "help".

David

Re: Release schedule

[Steven Bosscher]

Op za 28-09-2002, om 21:59 schreef David Edelsohn:
> 	When do you propose that major, new features be developed?  Our
> current schedule does not allocate any time for the extended effort
> required to design and implement major advances.  It does provide for
> merging major, new features in Stage 1, but new features cannot be
> developed in three months.

Development branches can exist for more than three months, so the
schedule is only part of the problem. 

One other part of the problem is that *too many* separate major
improvements are under development right now, and the GCC project simply
lack the resources to prepare a release-worthy GCC and have so many
development projects at the same time.

If there were only two or three projects, things would be much easier,
and developers would be able to develop major improvements and still
have time to fix bugs.

So apart from a new release schedule, maybe we need a new branching
policy.

> 	Because of the overlap between releases and development, GCC
> developers are forced to make a choice

Yes, and closing development branches in the weeks before branching
would "help" them make the choice ;-)

>  Many developers were unable to
> contribute major improvements they had planned for GCC 3.3 because they

Who had planned to contribute what, then, where is this plan? And why
isn't that part of the release plan?
I've said before that it's a *good* thing to document which improvements
should go in what release.

Greetz
Steven

Re: Release schedule

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> If necessary, I will ask the SC to close the various other development
Mark> branches.  Part of our problem is that we are all working on new C++
Mark> parsers, SIMPLE, loop optimizers, and all kinds of fun stuff -- not
Mark> fixing bugs.

Mark> We need to remind ourselves that teamwork requires the tedium of drills
Mark> in addition to the fun of playing games.

	When do you propose that major, new features be developed?  Our
current schedule does not allocate any time for the extended effort
required to design and implement major advances.  It does provide for
merging major, new features in Stage 1, but new features cannot be
developed in three months.

	Because of the overlap between releases and development, GCC
developers are forced to make a choice.  Many developers were unable to
contribute major improvements they had planned for GCC 3.3 because they
spent all their time in the GCC 3.1/3.2 release engineering process.  They
justifiably are not going to allow themselves to be placed in the same
predicament.

	The current GCC schedule is unworkable because it does not provide
any time when developers can have fun and make great strides without
affecting the release schedule.  The GCC schedule should be revised to
take this into account.

David

Re: Release schedule

[Roger Sayle]

I believe its safe to close high priority PR optimization/7147.
This problem was fixed both on gcc-3_2-branch and mainline by

2002-07-18  Richard Henderson  <rth@redhat.com>

        PR optimization/7147
        * ifcvt.c (noce_get_condition): Make certain that the condition
        is valid at JUMP.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Release schedule

[Mark Mitchell]

--On Saturday, September 28, 2002 04:15:29 PM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> On Wed, 25 Sep 2002, Mark Mitchell wrote:
>> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
>> that need to get in before we make that branch?
>
> I believe it would be a huge mistake branching with the high a number of
> _known_ regressions we currently have.  We should strive to fix most of
> these in stage 3, not on the release branch again.

I agree.  We neeed to do some bug-fixing work before we branch.

If necessary, I will ask the SC to close the various other development
branches.  Part of our problem is that we are all working on new C++
parsers, SIMPLE, loop optimizers, and all kinds of fun stuff -- not
fixing bugs.

We need to remind ourselves that teamwork requires the tedium of drills
in addition to the fun of playing games.

Thank you for the list of PRs.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Release schedule

[Gerald Pfeifer]

On Wed, 25 Sep 2002, Mark Mitchell wrote:
> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
> that need to get in before we make that branch?

I believe it would be a huge mistake branching with the high a number of
_known_ regressions we currently have.  We should strive to fix most of
these in stage 3, not on the release branch again.

In the past I have been a strong proponent of having a regular release
cycle, but perhaps we simply cannot sustain both a regular release
cycle and the high quality we claim (but do not really achieve) at
<http://gcc.gnu.org/gcc-3.1/criteria.html>?

Gerald

Re: Release schedule

[Gerald Pfeifer]

On Wed, 25 Sep 2002, Mark Mitchell wrote:
> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
> October 1st, with subsequent changes coming only with my approval.  Are
> there known regressions that we need to fix for GCC 3.2.1?

Yes, quite many.

GNATS currently has 70 PRs marked as high priority, most of which
indeed are regressions in 3.2. :-(

> If so, please mail PR numbers to me.

8066/c++
   ICE when compiling incorrect template class initialization
   Regression from 3.0.x

7856/target
   [arm] invalid offset in constant pool reference
   Regression from 3.0.

7822/libstdc++
   build failure gcc-3.2 CVS 20020830 on m68k-linux

7807/c++
   g++ 3.2 Fails to compile legal code that compiled OK with g++ 3.1
   Regression from 3.1

7796/middle-end
   Regression: sparc-sun-solaris2.7 extra failure w/-m64 on
   execute/930921-1.c in unroll.c

7788/c++
   g++-3.2 internal error: Segmentation fault
   Regression from 3.0.4 and 3.1.

7754/c++
   ICE SIGSEGV on union with template parameter
   Regression (confirmed by Nathan).

7743/c++
   g++-3.2 - Segmentation fault
   Regression with three line code snippet.

7721/c++
   Very simple (but incorrect) template chokes g++
   Regression (confirmed by Nathan).

7686/c++
   rejects-legal unassigned template compilation
   Regression from 3.0.4.

7679/c++
   The compiler crashes wen a right parentesis is missing
   Regression: 3.2 goes into endless loop

And many more, including the usual set of Ada bugs that nobody has been
actively working on.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Release schedule

[Zack Weinberg]

On Thu, Sep 26, 2002 at 10:51:08PM +0100, Joseph S. Myers wrote:
> On Thu, 26 Sep 2002, Florian Weimer wrote:
> 
> > There are a couple Ada-specific last-minute fixes from the GCC 3.1
> > release which *must* be ported to GCC 3.3 (e.g. fixing the bug box).
> 
> That's ada/6919 (priority "high") for the patches applied to the branch
> only, ada/5856 for the specific case of the bug box, plus ada/6558 for
> patches applied to the mainline then wrongly reverted.  The other "high"  
> priority Ada PR, ada/5907 for lack of a user manual, is mostly fixed: the
> manual is present and installed; it isn't included in the info directory
> for lack of a directory entry for install-info to work on but that hardly
> merits "high" priority.

It would be nice if these got fixed before we branch for 3.3 so that
this doesn't come up *again* in another six months.

zw

Re: Release schedule

[Joseph S. Myers]

On Thu, 26 Sep 2002, Florian Weimer wrote:

> There are a couple Ada-specific last-minute fixes from the GCC 3.1
> release which *must* be ported to GCC 3.3 (e.g. fixing the bug box).

That's ada/6919 (priority "high") for the patches applied to the branch
only, ada/5856 for the specific case of the bug box, plus ada/6558 for
patches applied to the mainline then wrongly reverted.  The other "high"  
priority Ada PR, ada/5907 for lack of a user manual, is mostly fixed: the
manual is present and installed; it isn't included in the info directory
for lack of a directory entry for install-info to work on but that hardly
merits "high" priority.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Release schedule

[Florian Weimer]

Mark Mitchell <mark@codesourcery.com> writes:

> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
> that need to get in before we make that branch?

I think the Ada breakage on Sparc still hasn't been addressed.

There are a couple Ada-specific last-minute fixes from the GCC 3.1
release which *must* be ported to GCC 3.3 (e.g. fixing the bug box).

Re: Release schedule

[Eric Botcazou]

> SECONDARY_MEMORY_NEEDED for subregs:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01539.html

It fixes an ICE for the following testcase:

/* { dg-do compile { target i?86-*-* } } */
/* { dg-options "-O -march=athlon" } */

void foo ()
{
  struct { float x, y; } c, *cp;
  static float z;

  while (1)
  {
     c.y = cp->y + cp->y;
     z   = c.y + 1.0;
  }
}

The testcase was extracted from PR optimization/7124 by Volker Reichelt. But
the patch is not sufficient for the submitter's testcase.

--
Eric Botcazou

Re: Release schedule

[Alexander Kabaev]

Hi Mark,

On Wed, 25 Sep 2002 11:28:50 -0700
Mark Mitchell <mark@codesourcery.com> wrote:

> I have been remiss in making announcements about the release schedule.
> 
> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
> October 1st, with subsequent changes coming only with my approval. 
> Are there known regressions that we need to fix for GCC 3.2.1?  If so,
> please mail PR numbers to me.

I just filled out PR preprocessor/8055 which describes the bug causing
CPP0 preprocessor to dump core on FreeBSD. The bug is not FreeBSD
specific, FreeBSD just happened to have the right combination of include
files to trickle it.

The patch I used to fix the problem is included with PR. Since I simply
copied and trivially modified a block of code from the top of the same
function, I hope my copyright assignment papers are not needed. 

-- 
Alexander Kabaev

Re: Release schedule

[David S. Miller]

   From: "David S. Miller" <davem@redhat.com>
   Date: Wed, 25 Sep 2002 13:08:54 -0700 (PDT)

   target/7842 is a very fundamental flaw in the sparc backend,...

This turned out the be simple to fix once I dug more deeply.
I've installed the fix and will be closing this bug shortly.

32-bit "sll" does not extend like shift right does, although
this is a peculiar behavior it is actually specified this way
in Sparc V9 and indeed how the cpu acts :-)

Checked into mainline and 3.2 branch.

2002-09-25  David S. Miller  <davem@redhat.com>

	PR target/7842
	* config/sparc/sparc.c (set_extends): SImode ASHIFT does not
	extend.

--- ./config/sparc/sparc.c.~1~	Sat May 25 19:42:21 2002
+++ ./config/sparc/sparc.c	Wed Sep 25 21:14:02 2002
@@ -8650,7 +8650,6 @@ set_extends (insn)
 	  return INTVAL (op1) >= 0;
 	return (GET_CODE (op1) == REG && sparc_check_64 (op1, insn) == 1);
       }
-    case ASHIFT:
     case LSHIFTRT:
       return GET_MODE (SET_SRC (pat)) == SImode;
       /* Positive integers leave the high bits zero.  */

Re: Release schedule

[Richard Earnshaw]

> I have been remiss in making announcements about the release schedule.
> 
> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
> October 1st, with subsequent changes coming only with my approval.  Are
> there known regressions that we need to fix for GCC 3.2.1?  If so, please
> mail PR numbers to me.

PR/7856 [arm] invalid offset in constant pool reference 

The problem is understood, but there's no fix yet.

Re: Release schedule

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
Mark> that need to get in before we make that branch?

GCSE fix (Mips regression fix):
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01557.html

-finline-limit:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00176.html

XCOFF DBX fix for function sections:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00459.html

IBM 128-bit extended floaing point format:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01463.html

C++ binding level reorg (fixes performance regression):
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01588.html
(this now has been approved but not applied)

SECONDARY_MEMORY_NEEDED for subregs:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01539.html

SSE_MATH macros:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01345.html

MINUS_EXPR:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01072.html

reg-alloc performance regression fix including x86 correctness fix:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00044.html

Re: Release schedule

[Devang Patel]

On Wednesday, September 25, 2002, at 01:15  PM, David Edelsohn wrote:

> C++ binding level reorg (fixes performance regression):
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01588.html
> (this now has been approved but not applied)

I have applied this to main trunk.

http://gcc.gnu.org/ml/gcc-cvs/2002-09/msg00596.html

Thank you,
-Devang
"Pursue joy, not happiness."

Re: Release schedule

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> > After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
> > that need to get in before we make that branch?
...
> Unshare RTL in reload:
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01534.html

This is already in mainline, applied by rth.

> stack smashing protector (useful for mudflap?):
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00042.html

This is not a bug-fix and so not suitable.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Release schedule

[Frank Ch. Eigler]

David Edelsohn <dje@watson.ibm.com> writes:

> [...]
> stack smashing protector (useful for mudflap?):
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00042.html
> [...]

While this work is interesting and looks effective, it uses different
technology (RTL-level) to solve a small (but important) subspace of
problems than mudflap does.  I don't think they naturally interconnect.

- FChE

Re: Release schedule

[David S. Miller]

target/7842 is a very fundamental flaw in the sparc backend, the test
case example in the gnats entry is just the tip of the iceberg.  In
v8plus and arch64 mode we provide all of the SImode patterns, and GCC
thinks that all of them clear out the upper 32-bits of the result in
the destination (only 32-bit shift right actually does).  Thus combine
eliminates a lot of zero/sign extend operation, in places where it
absolutely cannot do so legally.  One solution would be to not provide
the SImode variants in arch64 mode, but this is not a solution
because:

1) It doesn't handle the v8plus case at all, which is the instance
   being used by the target/7842 test case

2) It would require a complete verification and potential rewrite
   of the compare stuff for arch64 if we don't provide the SImode
   patterns.

So a simpler more direct fix is needed to cure this.

I've tried to work on this off and on, but currently I'm not
able to allot the amount of time to GCC that I would like
so it's unlikely that I'll be able to fix this in time for
3.2.1

Nevertheless it is a very important bug to have fixed.

Re: Release schedule

[David Edelsohn]

> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
> that need to get in before we make that branch?

GCSE fix (Mips regression fix):
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01557.html

-finline-limit:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00176.html

XCOFF DBX fix for function sections:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00459.html

IBM 128-bit extended floaing point format:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01463.html

C++ binding level reorg (fixes performance regression):
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01588.html
(this now has been approved but not applied)

Unshare RTL in reload:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01534.html

SECONDARY_MEMORY_NEEDED for subregs:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01539.html

SSE_MATH macros:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01345.html

MINUS_EXPR:
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01072.html

stack smashing protector (useful for mudflap?):
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00042.html

reg-alloc performance regression fix including x86 correctness fix:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00044.html

Re: Release schedule

[Michael Matz]

Hi,

On Wed, 25 Sep 2002, Mark Mitchell wrote:

> After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
> that need to get in before we make that branch?

http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00044.html
It's lingering since about a month now.  The change in ra-build doesn't
need approving, but it changes also defaults.h and i386/i386.h, so it
needs a global write person.  Sure, it's not strictly needed before the
branch, but somewhen it should go in.


Ciao,
Michael.

Re: Release schedule

[Dale Johannesen]

On Wednesday, September 25, 2002, at 11:28 AM, Mark Mitchell wrote:

> I have been remiss in making announcements about the release schedule.
>
> GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
> October 1st, with subsequent changes coming only with my approval.  Are
> there known regressions that we need to fix for GCC 3.2.1?

-finline-limit was still broken last I looked.
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00176.html

Release schedule

[Mark Mitchell]

I have been remiss in making announcements about the release schedule.

GCC 3.2.1 is scheduled for October 15.  I plan to close the branch on
October 1st, with subsequent changes coming only with my approval.  Are
there known regressions that we need to fix for GCC 3.2.1?  If so, please
mail PR numbers to me.

After GCC 3.2.1 goes out, we will branch for GCC 3.3.  Are there changes
that need to get in before we make that branch?

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com