Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

[Richard Kenner]

    The scenario I want to avoid is that we first reach 100% ACATS pass on
    the two targets (looks likely), then later a patch goes in that
    introduces 20 ACATS regressions on those two targets and the patch is
    not fixed or reverted following the usual rules for other components. 

Yes, but that's a *different* standard.  What you are talking about
if whether the commit rules will require running ACATS to commit a
patch.  The question raised was whether Ada should be part of the
release criteria.

These are not the same.

Re: Ada policy (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

On Mon, 2004-08-30 at 22:28, Richard Kenner wrote:
>     The scenario I want to avoid is that we first reach 100% ACATS pass on
>     the two targets (looks likely), then later a patch goes in that
>     introduces 20 ACATS regressions on those two targets and the patch is
>     not fixed or reverted following the usual rules for other components. 
> 
> Yes, but that's a *different* standard.  What you are talking about
> if whether the commit rules will require running ACATS to commit a
> patch.  

Sorry I wasn't clear on my intent. The commit rules don't require you to
test on all the platforms, but if someone report that you break one you
didn't test, it's still considered your fault and you should try to help
on the issue, and in some extreme cases the patch could be reverted (at
least that's my understanding).

This "platform" rule could also be applied to components, you don't
necessarily have to test Ada, but if someones points out
a breakage, you have to be helpful on the issue.

(BTW I didn't find on the web site a link to the 3.4 release criteria
page http://gcc.gnu.org/gcc-3.4/criteria.html, and didn't find one for
3.5 did I miss something?)

> The question raised was whether Ada should be part of the
> release criteria.
> 
> These are not the same.

May be but I must admit I fail to see the practical difference, if
you're not continuously looking in some way at regressions on one
platform or component for a full development cycle, it's unlikely that
you'll be able to reach any relase criteria involving this platform or
component at the end of the cycle (without potential delays).

The current rules differ on who should be "looking" at regressions
depending on component vs platform (the patch submitter or someone
else), but that's less important IMHO than having a consistent rule on
what to do when a regression is detected on a particular patch.

Laurent

Release criteria (was: Ada policy)

[Gerald Pfeifer]

On Mon, 30 Aug 2004, Laurent GUERBY wrote:
> (BTW I didn't find on the web site a link to the 3.4 release criteria
> page http://gcc.gnu.org/gcc-3.4/criteria.html, and didn't find one for
> 3.5 did I miss something?)

We started with very detailed (and agressive) release criteria for 3.0,
but somehow this didn't really work out, neither for 3.0 nor for later
releases, mostly due to the volunteer nature of the GCC project.

So I guess the closest thing we have these days is Mark's mental picture
of Bugzilla and open projects and the status mails he is sending.  I'm not
really sure how to formalize and write this down as a release criteria
documents.

Gerald

Re: Release criteria

[Robert Dewar]

Gerald Pfeifer wrote:
> On Mon, 30 Aug 2004, Laurent GUERBY wrote:

> So I guess the closest thing we have these days is Mark's mental picture
> of Bugzilla and open projects and the status mails he is sending.  I'm not
> really sure how to formalize and write this down as a release criteria
> documents.

I guess I would say I trust Mark's mental picture better than any
formal document written down :-)

Not that I am opposed to writing things down, not at all, but
formalizing release procedures is a very hard process (we know,
we have to go through this ourselves all the time, and in fact
we generally rely on judgment from the release manager, informed
by discussion in arguable cases, rather than trying to write
down a formal set of criteria, and that has worked well for us).
> 
> Gerald

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I notice that the, uh, "project" to get Ada bootstrapping (Kenner,
    when can we expect this?) is not listed.  These changes will
    presumably be accepted in stage 3?

Because it's not a "project" in the sense of new development, but rather
bugs that Ada triggers in middle-end code.   Fixing bugs is Stage 3 work.
So the timing of the Ada work is not relevent to entering Stage 3.

    However, I'm beginning to worry that Ada is going to delay the release
    of GCC 3.5 substantially if it's not bootstrapping soon, because the
    long period without Ada bootstrapping is likely to lead to bug
    discoveries when Ada is revived from the dead.

Well it was bootstrapping on and off but indeed various changes have broken
it for about two weeks.  Part of the reason for the long period was that I
was in Europe for a meeting for about a week.

In any event, as of yesterday afternoon, I have it bootstrapping in my tree.
It should be bootstrapping again in the GCC CVS in a day or so.  It'll be
more work to get it ACATS clean because some of the kludges I used to work
around bugs will need to be converted into the proper fix.

    Is Ada functioning a requirement for the release?  If so it seems a
    moderately bad idea to go into stage 3 with it totally busted.

The answer to the first question has always been "no".  But in practice,
my expectation is that it will work fine on the release.

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> >    Is Ada functioning a requirement for the release?  If so it seems a
> >    moderately bad idea to go into stage 3 with it totally busted.
> 
> The answer to the first question has always been "no".  But in practice,
> my expectation is that it will work fine on the release.

We had a barely working Ada compiler in 3.3 (fortunately enough for
bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
on x86 and x86_64 at -O2.

I believe it's reasonable now to make it a requirement that Ada works in
future GCC releases, at least on x86 and x86_64 with no regression.

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> > >    Is Ada functioning a requirement for the release?  If so it seems a
> > >    moderately bad idea to go into stage 3 with it totally busted.
> > 
> > The answer to the first question has always been "no".  But in practice,
> > my expectation is that it will work fine on the release.
> 
> We had a barely working Ada compiler in 3.3 (fortunately enough for
> bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass

Well, fully working on x86, not working in 3.4 on 64-bit architectures
and not working on ppc32 (while it worked in 3.3 on all of them).

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > on x86 and x86_64 at -O2.
>
> Well, fully working on x86, not working in 3.4 on 64-bit architectures
> and not working on ppc32 (while it worked in 3.3 on all of them).

3.3 did not have ACATS so working = bootstrap, which doesn't
mean much for end user (I know of no one successfully using Ada with FSF
3.3 except for bootstraping 3.4).

3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

(Also I believe s390 and s390x results were quite good before tree-ssa)

But back to the point, is not having *all* architectures perfectly
working for a language a reason to allow breaking of previously working
architectures? 

Is the requirement for not release GCC with broken Ada on x86 and x86_64
too strong?

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Florian Weimer]

* Laurent GUERBY:

> Is the requirement for not release GCC with broken Ada on x86 and x86_64
> too strong?

When was the last successful bootstrap of mainline, with Ada enabled?

I understand that Ada is already in much better shape than we expected
it to be before the tree-ssa merge (and that's certainly good news!),
but I really doubt we should make a release criterion the quality of a
component that has received very little testing by the general GCC
community.

Ada policy (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
> I understand that Ada is already in much better shape than we expected
> it to be before the tree-ssa merge (and that's certainly good news!),
> but I really doubt we should make a release criterion the quality of a
> component that has received very little testing by the general GCC
> community.

I'm just talking about bootstrap, passing ACATS and no known regression
on two targets, not "quality" in general (whatever that means).

The scenario I want to avoid is that we first reach 100% ACATS pass on
the two targets (looks likely), then later a patch goes in that
introduces 20 ACATS regressions on those two targets and the patch is
not fixed or reverted following the usual rules for other components. 

Is that what you want for Ada now? If not, why not spell it out clearly
to avoid discussions with no time left later on? Also
if this rule is not set now, I see no reason for it to be set later
then, and that's not good news for the GNU Compiler _Collection_
Ada-wise.

Laurent

PS: I have tested and will test again at work our 500 KSLOC software
with FSF CVS.