Re: GCC 3.1 Branch

Re: GCC 3.1 Branch

[Richard Kenner]

    I intend to create the GCC 3.1 branch sometime tomorrow.

    If you know of a reason why we should not create the branch, please
    let me know.  (I'm not sure what this would be, but just in case...)

At the moment, Sparc doesn't bootstrap.  It would be nice to get this
fixed and then wait at least a day for some testing before the branch.
I'd suggest Monday, assuming it actually is fixed tonight.

Re: GCC 3.1 Branch

[David Edelsohn]

>>>>> Richard Kenner writes:

> I intend to create the GCC 3.1 branch sometime tomorrow.
> If you know of a reason why we should not create the branch, please
> let me know.  (I'm not sure what this would be, but just in case...)

Richard> At the moment, Sparc doesn't bootstrap.  It would be nice to get this
Richard> fixed and then wait at least a day for some testing before the branch.
Richard> I'd suggest Monday, assuming it actually is fixed tonight.

	I agree that this recently introduced Sparc bootstrap failure
should be fixed before a branch is made.

David

Re: GCC 3.1 Branch

[Alexandre Oliva]

On Feb 21, 2002, David Edelsohn <dje@watson.ibm.com> wrote:

>>>>>> Richard Kenner writes:
>> I intend to create the GCC 3.1 branch sometime tomorrow.
>> If you know of a reason why we should not create the branch, please
>> let me know.  (I'm not sure what this would be, but just in case...)

Richard> At the moment, Sparc doesn't bootstrap.  It would be nice to get this
Richard> fixed and then wait at least a day for some testing before the branch.
Richard> I'd suggest Monday, assuming it actually is fixed tonight.

> 	I agree that this recently introduced Sparc bootstrap failure
> should be fixed before a branch is made.

So, is any SPARC maintainer stepping forward to help me out with the
brokenness of sparcv9?

Or perhaps I could go ahead and install the part of the patch that RTH
didn't say that would require further investigation?  Perhaps this
would be enough to get at least non-v9 sparc going again.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC 3.1 Branch

[H . J . Lu]

On Thu, Feb 21, 2002 at 09:57:17PM -0500, David Edelsohn wrote:
> >>>>> Richard Kenner writes:
> 
> > I intend to create the GCC 3.1 branch sometime tomorrow.
> > If you know of a reason why we should not create the branch, please
> > let me know.  (I'm not sure what this would be, but just in case...)
> 
> Richard> At the moment, Sparc doesn't bootstrap.  It would be nice to get this
> Richard> fixed and then wait at least a day for some testing before the branch.
> Richard> I'd suggest Monday, assuming it actually is fixed tonight.
> 
> 	I agree that this recently introduced Sparc bootstrap failure
> should be fixed before a branch is made.
> 

Has anyone looked into the i586 C++ EH problem? It will be nice to see
it fixed before 3.1. Also -g1 for stabs/dwarf-2 is broken/useless for
gdb in the current gcc. Even a simple backstrace doesn't work with -g1.
If there is no plan to fix it, which I don't mind, shouldn't we compile
libgcc with -g0 or -g.


H.J.

Re: GCC 3.1 Branch

[David Edelsohn]

>>>>> H J Lu writes:

HJ> Has anyone looked into the i586 C++ EH problem? It will be nice to see
HJ> it fixed before 3.1. Also -g1 for stabs/dwarf-2 is broken/useless for
HJ> gdb in the current gcc. Even a simple backstrace doesn't work with -g1.
HJ> If there is no plan to fix it, which I don't mind, shouldn't we compile
HJ> libgcc with -g0 or -g.

	HJ, this is a branch for GCC 3.1, not a release.

David

Re: GCC 3.1 Branch

[Alexandre Oliva]

On Feb 21, 2002, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> At the moment, Sparc doesn't bootstrap.

I'll be working on a fix shortly.  I don't mind having to install the
patch on branch and mainline.  You can already get to test the patch I
posted two days ago or so.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

GCC 3.1 Branch

[Mark Mitchell]

Now that GCC 3.1 has been released, the 3.1 branch is again open for
checkins.

Let's review the policy for the branch:

1. Anyone who can normally approve patches can approve patches that
   fix regressions from previously released versions of GCC.

2. I will review and approve patches that do not fix regressions if

   a) they appear safe
   b) they fix very important problems, or
   c) they add support for new platforms, language features, etc.
      that we did not support before -- and that we cannot, therefore,
      be regressing.

   Please make your case explicitly; assume I know very little (a
   good assumption!) and explain why your patch fits these criteria.

GCC 3.1.1 is now scheduled for July 15th.  I would very much like to
avoid lots of bug-fies at the last minute; please expect the branch
to close in late June, and get your fixes in before then.

Thanks!

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

Re: GCC 3.1 Branch

[Aldy Hernandez]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

 >    c) they add support for new platforms, language features, etc.
 >       that we did not support before -- and that we cannot, therefore,
 >       be regressing.

Great.  I'd like permission to check in my cleanups to the user level
include file: <altivec.h>

There are some major fixes without which, altivec support isn't going
to be very useful.

Aldy

Re: GCC 3.1 Branch

[Daniel Jacobowitz]

On Fri, May 17, 2002 at 11:56:52AM +1000, Aldy Hernandez wrote:
> >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> 
>  >    c) they add support for new platforms, language features, etc.
>  >       that we did not support before -- and that we cannot, therefore,
>  >       be regressing.
> 
> Great.  I'd like permission to check in my cleanups to the user level
> include file: <altivec.h>
> 
> There are some major fixes without which, altivec support isn't going
> to be very useful.

Are you considering backporting the more important backend changes,
also?  I don't know how practical it is, but lots of people would
appreciate it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC 3.1 Branch

[Aldy Hernandez]

On Fri, May 17, 2002 at 12:12:37AM -0400, Daniel Jacobowitz wrote:
> On Fri, May 17, 2002 at 11:56:52AM +1000, Aldy Hernandez wrote:
> > >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> > 
> >  >    c) they add support for new platforms, language features, etc.
> >  >       that we did not support before -- and that we cannot, therefore,
> >  >       be regressing.
> > 
> > Great.  I'd like permission to check in my cleanups to the user level
> > include file: <altivec.h>
> > 
> > There are some major fixes without which, altivec support isn't going
> > to be very useful.
> 
> Are you considering backporting the more important backend changes,
> also?  I don't know how practical it is, but lots of people would
> appreciate it.

hmm, i'm afraid mark said no.

Re: GCC 3.1 Branch

[Mark Mitchell]

--On Friday, May 17, 2002 03:31:14 PM +1000 Aldy Hernandez 
<aldyh@redhat.com> wrote:

> On Fri, May 17, 2002 at 12:12:37AM -0400, Daniel Jacobowitz wrote:
>> On Fri, May 17, 2002 at 11:56:52AM +1000, Aldy Hernandez wrote:
>> > >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>> >
>> >  >    c) they add support for new platforms, language features, etc.
>> >  >       that we did not support before -- and that we cannot,
>> >  >       therefore, be regressing.
>> >
>> > Great.  I'd like permission to check in my cleanups to the user level
>> > include file: <altivec.h>
>> >
>> > There are some major fixes without which, altivec support isn't going
>> > to be very useful.
>>
>> Are you considering backporting the more important backend changes,
>> also?  I don't know how practical it is, but lots of people would
>> appreciate it.
>
> hmm, i'm afraid mark said no.

Unless they fix regressions, I'm not inclined to take the risk.  Tweaking
back ends is a very easy way to introduce subtle code-gen bugs.

Of  course, that's not a hard and fast rule.

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

Re: GCC 3.1 Branch

[Mark Mitchell]

--On Friday, May 17, 2002 11:56:52 AM +1000 Aldy Hernandez 
<aldyh@redhat.com> wrote:

>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>  >    c) they add support for new platforms, language features, etc.
>  >       that we did not support before -- and that we cannot, therefore,
>  >       be regressing.
>
> Great.  I'd like permission to check in my cleanups to the user level
> include file: <altivec.h>

That's fine; a good example of the kind of thing that's OK.

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

Re: GCC 3.1 Branch

[Aldy Hernandez]

> That's fine; a good example of the kind of thing that's OK.

thanks.  there were obvious changes to begin with.  will i need
further approval, or should i just check the <altivec.h> changes in?

aldy

Re: GCC 3.1 Branch

[Mark Mitchell]

--On Friday, May 17, 2002 04:08:42 PM +1000 Aldy Hernandez 
<aldyh@redhat.com> wrote:

>
>> That's fine; a good example of the kind of thing that's OK.
>
> thanks.  there were obvious changes to begin with.  will i need
> further approval, or should i just check the <altivec.h> changes in?

You should follow whatever procedures you would follow on the mainline.

I don't remember if you need approval for your work, or whether you've
been appointed a maintainer for your work.  If the latter, you can
just use your judgement; if the former, you need to post your patch and
get a review.

Thanks,

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

GCC 3.1 Branch

[Mark Mitchell]

I have created the GCC 3.1 branch.

I have also checked in "branching.html" to the web site, which contains
the instructions Joseph came up with for creating branches.

At this point, the 3.1 branch is now a release branch; that means that
check-ins there should address regressions from previous releases of
GCC.  There is no need to get my approval for check-ins at this time.

Meanwhile, the mainline is what will eventually become GCC 3.2.  All
check-ins are acceptable on the mainline, assuming that they receive
appropriate approvals.

The GCC 3.1 release is scheduled for April 15th.  That means that we
need to stop development on the branch by April 1st, which gives us
almost exactly one month for stabilization.  (We are getting a late
start due to the combination of a late 3.0.4 release and unexpected
turbulence on the mainline.)  If we need more time to get GCC 3.1
in shape, I will ask the SC to approve an extension.  However, at this
point, we will stick with the original schedule.

Yours,

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

Re: GCC 3.1 Branch

[Corey Minyard]

It doesn't look like the big GNAT merge made it.  Just curious if that's 
enough to delay, or if that will be 3.2.

-Corey

Mark Mitchell wrote:

> I have created the GCC 3.1 branch.
>
> I have also checked in "branching.html" to the web site, which contains
> the instructions Joseph came up with for creating branches.
>
> At this point, the 3.1 branch is now a release branch; that means that
> check-ins there should address regressions from previous releases of
> GCC.  There is no need to get my approval for check-ins at this time.
>
> Meanwhile, the mainline is what will eventually become GCC 3.2.  All
> check-ins are acceptable on the mainline, assuming that they receive
> appropriate approvals.
>
> The GCC 3.1 release is scheduled for April 15th.  That means that we
> need to stop development on the branch by April 1st, which gives us
> almost exactly one month for stabilization.  (We are getting a late
> start due to the combination of a late 3.0.4 release and unexpected
> turbulence on the mainline.)  If we need more time to get GCC 3.1
> in shape, I will ask the SC to approve an extension.  However, at this
> point, we will stick with the original schedule.
>
> Yours,
>

Re: GCC 3.1 Branch

[Mark Mitchell]

--On Tuesday, February 26, 2002 09:39:30 AM -0600 Corey Minyard 
<minyard@acm.org> wrote:

> It doesn't look like the big GNAT merge made it.  Just curious if that's
> enough to delay, or if that will be 3.2.

GNAT is not a priority for the FSF GCC releases yet.  We have made no
committments regarding GNAT at this time, and I would not anticipate
holding up the 3.1 release for GNAT.  However, the GNAT developers
are welcome to make any checkins they like on the branch that do not
affect the rest of the compiler; the ususal strictures about regressions
and such don't apply to languages that aren't part of the release
committment.

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

GCC 3.1 Branch

[Mark Mitchell]

I intend to create the GCC 3.1 branch sometime tomorrow.

If you know of a reason why we should not create the branch, please
let me know.  (I'm not sure what this would be, but just in case...)

Thank you,

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

Re: GCC 3.1 Branch

[Joseph S. Myers]

On Thu, 21 Feb 2002, Mark Mitchell wrote:

> I intend to create the GCC 3.1 branch sometime tomorrow.

Since there's no documentation of creating release branches, a probably
incomplete list of places that need changing:

* cvs.html, list of tags.
* index.html, news entry.

* All [vV]ersion.c files on the branch, to say "prerelease" instead of 
"experimental".

* All [vV]ersion.c files on the mainline, to say 3.2 instead of 3.1 (and 
to say 0.5.28 as the G77 version number, since the separate G77 version 
number hasn't been eliminated yet).

* The mainline doc/include/gcc-common.texi, to change the version number 
to 3.2.  Since other manuals aren't yet using this file to get versions, 
java/gcj.texi and f/root.text also need updating; f/root.texi also needs 
the G77 version updating.

* Branch f/root.texi, to @clear DEVELOPMENT.

* Mainline maintainer-scripts/gcc_release, where it says "# For now
snapshots come from the mainline.", to make snapshots come from the branch 
instead.  (cvs update will also need to be run in the scripts directory in 
the gccadmin account, to update the version actually called from cron.)

* gcc.pot should be regenerated just before the branch (or just after, on
mainline and branch), and a new snapshot from the branch created, and that
snapshot submitted to the translation project.  (At least until the 3.1
release, translation effort should be for the branch rather than the
mainline.)

* I'll deal with adjusting the references to c99status.html in the docs on
the branch to refer to a copy with the 3.1 status.

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

Re: GCC 3.1 Branch

[Joseph S. Myers]

On Fri, 22 Feb 2002, I wrote:

> Since there's no documentation of creating release branches, a probably
> incomplete list of places that need changing:

Another place: gccadmin's crontab (in CVS in maintainer-scripts and
installed on gcc.gnu.org for use by cron), to add an update_version call
for the 3.1 branch.

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

Re: GCC 3.1 Branch

[Toon Moene]

"Joseph S. Myers" wrote:

> * All [vV]ersion.c files on the mainline, to say 3.2 instead of 3.1 (and
> to say 0.5.28 as the G77 version number, since the separate G77 version
> number hasn't been eliminated yet).

If there's consensus about this issue, I'm all for removing the separate
g77 and libf2c version numbers.  Just say so and I will effect it once
the 3.2 branch is created.

[ Not immediately though - I'm off-line next week due to the 160th
  Fortran Standardisation Committee meeting - http://www.j3-fortran.org
]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.1 Branch

[Mark Mitchell]

--On Friday, February 22, 2002 08:14:21 PM +0100 Toon Moene 
<toon@moene.indiv.nluug.nl> wrote:

> "Joseph S. Myers" wrote:
>
>> * All [vV]ersion.c files on the mainline, to say 3.2 instead of 3.1 (and
>> to say 0.5.28 as the G77 version number, since the separate G77 version
>> number hasn't been eliminated yet).
>
> If there's consensus about this issue, I'm all for removing the separate
> g77 and libf2c version numbers.  Just say so and I will effect it once
> the 3.2 branch is created.

Nobody has spoken out against, and I am for, so let's call that
consensus.

If you can, try to reduce the total number of version.c files in the
process.

Thanks,

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

Re: GCC 3.1 Branch

[David O'Brien]

On Thu, Feb 21, 2002 at 04:44:55PM -0800, Mark Mitchell wrote:
> I intend to create the GCC 3.1 branch sometime tomorrow.

Now that the sparc64 issue is dealt with, is there an ETA on 3.1
branching?