Re: Freeze timing and questions

Re: Freeze timing and questions

[Richard Kenner]

    Right now it attempts to bootstrap ada when it finds an old version of
    gnatcc distributed by some linux vendor on one i386 machine I use, and
    that leads to a bootstrap failure.  

You may recall that I was against the widening of the test for an
existing Ada compiler for just this reason, but most people felt
diferently.

Re: Freeze timing and questions

[guerby]

> You may recall that I was against the widening of the test for an
> existing Ada compiler for just this reason, but most people felt
> diferently.

And the argument at the time was let's see what existing Ada compilers
are known to work, since ACT people were strongly implying than the
ALT RPM compiler would cause trouble.

I'd say from day to day builds in the few past monthes that 3.13p from
ACT tarball and RPM from ALT on i386-linux are both working perfectly
fine - I've been working exclusively with the ALT one except for the
first days, I assume ACT is working with some 3.13 version
installed. We want to reject versions < 3.13 since GNAT has always
required version N-1 or above to build.

My preference would be to recognize them on i386-linux and enable Ada
if a known to work version is found. Same reasoning possible on
platforms, looks like on mingw32 we have someone taking care of GNAT
:). (Assuming by the time of the 3.1 release the Ada compiler is known
to be in good shape of course.)

But I have no strong feeling for 3.1 on this point, if people think it
turns out to be just safer to disable Ada by default, I have no
problem with that. 

I don't think it is necessary to commit a decision right now though,
having it still enabled for a while will give us a bit more
information on what's working and what's not, improving Ada configure
machinery, etc. If we don't have problem reports we probably won't
have an Ada compiler working well out of the box on lots of platforms.

As for GCC release criteria, Ada should not be one for 3.1, but 3.2
Ada should not have regressions against what was achieved for 3.1 :).

PS: my day job will hopefully stop drifting to a night job tomorrow
since I'll be on vacation for one week with three days of full
internet access and nothing scheduled (except watching LOTR :).

-- 
Laurent Guerby <guerby@acm.org>

Re: Freeze timing and questions

[Joseph S. Myers]

On Mon, 17 Dec 2001 guerby@acm.org wrote:

> My preference would be to recognize them on i386-linux and enable Ada
> if a known to work version is found. Same reasoning possible on
> platforms, looks like on mingw32 we have someone taking care of GNAT
> :). (Assuming by the time of the 3.1 release the Ada compiler is known
> to be in good shape of course.)

My preference would be for configure to test for some feature of GNAT that
the current front end needs, is simple to test for, is in 3.13, and is not
in 3.12, then accept the Ada compiler as working (under any of the names
listed in configure) if the test for that feature passes.

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

Re: Freeze timing and questions

[Richard Kenner]

    Yes.  Let's by all means be flexible; I will not personally jump
    down anyone's throat about anything here.  On the other hand, as
    reviewers, let's please try to be conservative, and stay within
    the spirit of the thing: patches that fix problems in the compiler.

I think we also need to vary things over time.  We should be much more
likely to consider something that's somewhere between a new feature and a
bug fix as a bug fix now than we would in five weeks.

Re: Freeze timing and questions

[Mark Mitchell]

--On Tuesday, December 18, 2001 07:00:38 AM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     Yes.  Let's by all means be flexible; I will not personally jump
>     down anyone's throat about anything here.  On the other hand, as
>     reviewers, let's please try to be conservative, and stay within
>     the spirit of the thing: patches that fix problems in the compiler.
>
> I think we also need to vary things over time.  We should be much more
> likely to consider something that's somewhere between a new feature and a
> bug fix as a bug fix now than we would in five weeks.

No, not really.

We need to start being pretty aggressive *right now* so that on
February 15th the compiler is really pretty close to ready to go.

I've seen what happens here when we're not aggressive, and what happens
is we end up with 400 little, but very important bugs.

If things aren't going well, I'll step in, but I'm hoping that we'll
all just show the professionalism required to fix things by ourselves.

Let's not debate it; let's do it.

GNATS has thousands of bug reports; let's start closing them.

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

Re: Freeze timing and questions

[lucier]

Re:

>      I think we should have Ada:
> 
>      - Not part of the release criteria
> 
> Certainly.
> 
>      - Off by default
> 
> Well, right now it's off if you don't already have an Ada.  I think that's
> probably a good default, but don't have a strong opinion on the subject.

Right now it attempts to bootstrap ada when it finds an old version of
gnatcc distributed by some linux vendor on one i386 machine I use, and
that leads to a bootstrap failure.  So right now it's on by default
if you have an old gnatcc that won't bootstrap the ada compiler.

So I agree with Mark; it should be off by default.  Or you guys will get
a lot of bootstrap failure reports on release.

Brad

Re: Freeze timing and questions

[Richard Kenner]

    I think we should have Ada:

     - Not part of the release criteria

Certainly.

     - Off by default

Well, right now it's off if you don't already have an Ada.  I think that's
probably a good default, but don't have a strong opinion on the subject.

Re: Freeze timing and questions

[Mark Mitchell]

--On Monday, December 17, 2001 03:31:19 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     I think we should have Ada:
>
>      - Not part of the release criteria
>
> Certainly.
>
>      - Off by default
>
> Well, right now it's off if you don't already have an Ada.  I think that's
> probably a good default, but don't have a strong opinion on the subject.

That's OK with me.

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

Re: Freeze timing and questions

[Richard Kenner]

    The point is to spend the next couple of months stabilizing the
    compiler.  That means that we find important bugs, from GNATS or
    elsewhere, and try to fix them.  It's OK if they're not regressions;
    now is a great time to fix that horrible bug that's been annoying you
    since 1996.  We are now, however, focusing on quality -- not new items
    for the 3.1 release announcement bullet list.

This is somewhat ambiguous as to what "important" means, but I'd
suggest a criteria that looks at the fix.  A local fix is acceptable
even for a minor bug, but fixes that are more complex or riskier for
some reason should only be done for more important bugs.

    This is OK, but at this point I think it is unreasonable to actually
    support Chill in 3.1; its status would be equivalent to the KDE
    patches in the contrib/ directory.

A trickier question is what about Ada?  Active work is under way to get
the current sources to work with 3.1, but so far the complete ACT test
suite has not passed on *any* target, though it's getting closer (probably
under a half dozen distinct problems on x86).  Since test suites for Ada have
not yet been set up in the GCC tree, there's a tradeoff between pulling over
all front-end changes from ACT, whether bugfixes or new features, which have
been heavily tested, or copying over just the bugfixes, resulting in a
source tree that hasn't been as tested.  My feeling is that the first is
best, at least for another few weeks or until the sources start passing
the complete test suite, but I'm not sure.

Re: Freeze timing and questions

[Mark Mitchell]

--On Monday, December 17, 2001 12:49:02 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     The point is to spend the next couple of months stabilizing the
>     compiler.  That means that we find important bugs, from GNATS or
>     elsewhere, and try to fix them.  It's OK if they're not regressions;
>     now is a great time to fix that horrible bug that's been annoying you
>     since 1996.  We are now, however, focusing on quality -- not new items
>     for the 3.1 release announcement bullet list.
>
> This is somewhat ambiguous as to what "important" means, but I'd
> suggest a criteria that looks at the fix.  A local fix is acceptable
> even for a minor bug, but fixes that are more complex or riskier for
> some reason should only be done for more important bugs.

I do not think there is any benefit to trying to define this too precisely,
but what you say makes sense.

I do not want to over-constrain people.

Ideally, I think, people would go through GNATS and fix things that they
think they are able to fix.  That is what I plan to do personally, with
the time that I have available.  Reviewers should in general discourage
fixes of the form "the register allocator was broken, so I wrote a new
one" preferring, instead, "the register allocator did not correctly
handle multiple abnormal critical edges in a flow graph; fixed thusly".

>     This is OK, but at this point I think it is unreasonable to actually
>     support Chill in 3.1; its status would be equivalent to the KDE
>     patches in the contrib/ directory.
>
> A trickier question is what about Ada?  Active work is under way to get

I believe that we have already agreed that Ada will not be part of
this release.

Therefore, I think the Ada people should be free to do whatever they
like, so long as it does not affect other languages.

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

Re: Freeze timing and questions

[Geert Bosch]

On Monday, December 17, 2001, at 02:56 , Mark Mitchell wrote:

> I believe that we have already agreed that Ada will not be part of
> this release.
>
> Therefore, I think the Ada people should be free to do whatever they
> like, so long as it does not affect other languages.

I would like to continue integrating ACT changes for a while, since
the integration of the Ada front end is improving quickly. The slow
down in GCC development and hopefully reduced breakage of ports like 
Sparc/Solaris
will be a big help in moving forward with various ports.

BTW, I had not heard about the decision to not include Ada in this 
release,
but I think that may be a good idea.

   -Geert

Re: Freeze timing and questions

[Joseph S. Myers]

On Mon, 17 Dec 2001, Geert Bosch wrote:

> > I believe that we have already agreed that Ada will not be part of
> > this release.
> >
> > Therefore, I think the Ada people should be free to do whatever they
> > like, so long as it does not affect other languages.
> 
> I would like to continue integrating ACT changes for a while, since
> the integration of the Ada front end is improving quickly. The slow
> down in GCC development and hopefully reduced breakage of ports like 
> Sparc/Solaris
> will be a big help in moving forward with various ports.
> 
> BTW, I had not heard about the decision to not include Ada in this 
> release,
> but I think that may be a good idea.

So far, we have been advertising that Ada *will* be part of 3.1, on the
website, in both index.html and frontends.html.  Of course, we can say it
will be part of the release but not of the release criteria (as for Java
in 3.0) and warn it may not work on all the important platforms.

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

Re: Freeze timing and questions

[Mark Mitchell]

> So far, we have been advertising that Ada *will* be part of 3.1, on the
> website, in both index.html and frontends.html.  Of course, we can say it
> will be part of the release but not of the release criteria (as for Java
> in 3.0) and warn it may not work on all the important platforms.

I did not recollect that; it appears I spoke out of turn.

I do think it makes a lot of sense to treat Ada like Java in 3.0.

There is nothing to benchmark it against in terms of FSF releases

I think we should have Ada:

 - Not part of the release criteria

 - Off by default

 - Leave changes at the sole discretion of the Ada team, so long as
   they don't affect the rest of the code.

Ideally, this release will provide feedback about the FSF Ada compiler,
and we can then fix problems and turn it on by default in the 3.2
series.

That's my opinion, and not a binding decision.

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

Freeze timing and questions

[Joseph S. Myers]

According to develop.html, GCC 3.1 Phase 2 ends Dec 15 2001 (today) and
Phase 3 begins where

   During this period, the only changes that may be made to the compiler
   are changes that fix bugs. New functionality may not be introduced
   during this period.

(a) What's the exact time of the transition to Phase 3 (feature freeze)?

(b) What's the list of important targets for 3.1?

(c) Is there any further guidance on what classes of changes are
acceptable during this period, in particular about the following:

  (i) Changes that fix known/reported bugs, but where a proper fix
  involves new functionality (e.g. implementing a language feature that
  was broken and only worked partially / by accident).

  (ii) Deliberately removing or deprecating undocumented extensions, or
  making the compiler reject code it ought to reject but hadn't previously
  checked for.

  (iii) Deliberately removing or deprecating documented extensions.

  (iv) New CPU ports (which don't have the risk of affecting other code).

  (v) New OS ports for already supported CPUs.

  (vi) Documentation work (possibly with associated Makefile changes) that
  makes improvements that are not bug fixes.

  (vii) Fixing currently bitrotten and disabled front ends (i.e. Chill, if
  our volunteer to fix it gets the time to do so).

?

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

Re: Freeze timing and questions

[David O'Brien]

On Sat, Dec 15, 2001 at 08:57:32PM +0000, Joseph S. Myers wrote:
> (c) Is there any further guidance on what classes of changes are
> acceptable during this period, in particular about the following:
... 
>   (v) New OS ports for already supported CPUs.

I would still like to get the FreeBSD/sparc64 support committed for 3.1.
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01067.html
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Freeze timing and questions

[Mark Mitchell]

--On Saturday, December 15, 2001 08:57:32 PM +0000 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> According to develop.html, GCC 3.1 Phase 2 ends Dec 15 2001 (today) and
> Phase 3 begins where

In a rare nod to the historical "weekend" custom, I took Saturday and
Sunday off.  I would have posted a message this morning, but since you
beat me to it, I'll just reply to yours.

>    During this period, the only changes that may be made to the compiler
>    are changes that fix bugs. New functionality may not be introduced
>    during this period.

Yes.

The point is to spend the next couple of months stabilizing the compiler.
That means that we find important bugs, from GNATS or elsewhere, and
try to fix them.  It's OK if they're not regressions; now is a great
time to fix that horrible bug that's been annoying you since 1996.  We
are now, however, focusing on quality -- not new items for the 3.1
release announcement bullet list.

> (a) What's the exact time of the transition to Phase 3 (feature freeze)?

11:59 PM, GMT -0800, Monday, Dec 17. 2001.

> (b) What's the list of important targets for 3.1?

I do not have an answer to this one.  I do not believe the SC has
come up with a list, which is too bad.  Unless we here otherwise,
I guess we will have to stick with the 3.0 list.

> (c) Is there any further guidance on what classes of changes are
> acceptable during this period, in particular about the following:
>
>   (i) Changes that fix known/reported bugs, but where a proper fix
>   involves new functionality (e.g. implementing a language feature that
>   was broken and only worked partially / by accident).

On a case by case basis.  Anyone can approve the change, but we should
be looking for relatively minimal changes to solve problems.

>   (ii) Deliberately removing or deprecating undocumented extensions, or
>   making the compiler reject code it ought to reject but hadn't previously
>   checked for.

That is OK, except that people might decide that the extensions were
important, and should be documented, not reported.

>   (iii) Deliberately removing or deprecating documented extensions.

Case by case basis.  We should avoid doing this unless it is really
necessary; we are trying to create as few disturbances as possible.

>   (iv) New CPU ports (which don't have the risk of affecting other code).
>
>   (v) New OS ports for already supported CPUs.

Both OK, as long as they do not affect other code.

>   (vi) Documentation work (possibly with associated Makefile changes) that
>   makes improvements that are not bug fixes.

Always OK.

>   (vii) Fixing currently bitrotten and disabled front ends (i.e. Chill, if
>   our volunteer to fix it gets the time to do so).

This is OK, but at this point I think it is unreasonable to actually
support Chill in 3.1; its status would be equivalent to the KDE patches
in the contrib/ directory.

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

Re: Freeze timing and questions

[Toon Moene]

Mark Mitchell wrote:

[ .... Freeze ... ]
> In a rare nod to the historical "weekend" custom, I took Saturday and
> Sunday off.  I would have posted a message this morning, but since you
> beat me to it, I'll just reply to yours.

[ Sigh ]

Mark, by the time you decide to *do* something on a Monday morning
(i.e., after sipping your first coffee), Europe, to say nothing of the
rest of the world, already completed one full work day.

Think UTC !

-- 
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: Freeze timing and questions

[Mark Mitchell]

--On Monday, December 17, 2001 09:03:12 PM +0100 Toon Moene 
<toon@moene.indiv.nluug.nl> wrote:

> Mark Mitchell wrote:
>
> [ .... Freeze ... ]
>> In a rare nod to the historical "weekend" custom, I took Saturday and
>> Sunday off.  I would have posted a message this morning, but since you
>> beat me to it, I'll just reply to yours.
>
> [ Sigh ]
>
> Mark, by the time you decide to *do* something on a Monday morning
> (i.e., after sipping your first coffee), Europe, to say nothing of the
> rest of the world, already completed one full work day

What would you suggest is a fair warning period?

Since December 15th had been announced as the cutoff date months ago,
I think it's fair to say that the 17th is actually an extension.

However, in order to defuse charges of Ameri-centrism, I have asked
Emacs to pick a random number between 0 and 23 to add to the date
that I gave.  It said 17.  So, the cutoff will be:

  16:59 GMT -0800 2001-12-18

So, Europeans, you now have no excuses. :-)

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

Re: Freeze timing and questions

[Toon Moene]

Mark Mitchell wrote:

> --On Monday, December 17, 2001 09:03:12 PM +0100 Toon Moene
> <toon@moene.indiv.nluug.nl> wrote:
> 
> > Mark Mitchell wrote:
> >
> > [ .... Freeze ... ]
> >> In a rare nod to the historical "weekend" custom, I took Saturday and
> >> Sunday off.  I would have posted a message this morning, but since you
> >> beat me to it, I'll just reply to yours.
> >
> > [ Sigh ]
> >
> > Mark, by the time you decide to *do* something on a Monday morning
> > (i.e., after sipping your first coffee), Europe, to say nothing of the
> > rest of the world, already completed one full work day
> 
> What would you suggest is a fair warning period?

I was not commenting on the warning period, but your remark "I would
have posted a message this morning ...".

If *you* take the weekend off that means that to most of the rest of the
world Monday has gone too ;-)

-- 
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: Freeze timing and questions

[Richard Henderson]

On Mon, Dec 17, 2001 at 10:29:24AM -0800, Mark Mitchell wrote:
> > (a) What's the exact time of the transition to Phase 3 (feature freeze)?
> 
> 11:59 PM, GMT -0800, Monday, Dec 17. 2001.

Due to patch review backlog, I think that anything posted to 
gcc-patches before last Friday should be given a fair chance.
That said, these leftovers should be addressed promptly, and
if someone has one outstanding they should send prodding mail.

Does this seem reasonable?


r~

Re: Freeze timing and questions

[Mark Mitchell]

--On Monday, December 17, 2001 01:19:34 PM -0800 Richard Henderson 
<rth@redhat.com> wrote:

> On Mon, Dec 17, 2001 at 10:29:24AM -0800, Mark Mitchell wrote:
>> > (a) What's the exact time of the transition to Phase 3 (feature
>> > freeze)?
>>
>> 11:59 PM, GMT -0800, Monday, Dec 17. 2001.
>
> Due to patch review backlog, I think that anything posted to
> gcc-patches before last Friday should be given a fair chance.
> That said, these leftovers should be addressed promptly, and
> if someone has one outstanding they should send prodding mail.
>
> Does this seem reasonable?

Yes.  Let's by all means be flexible; I will not personally jump
down anyone's throat about anything here.  On the other hand, as
reviewers, let's please try to be conservative, and stay within
the spirit of the thing: patches that fix problems in the compiler.

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