Re: Ada mainline

Re: Ada mainline

[Richard Kenner]

    No it isn't.  You were doing mega dumps before tree-ssa merged,
    back when Ada supposedly worked.

Yes, to get caught up.  And then he did them daily.

Re: Ada mainline

[Daniel Berlin]

On Sep 9, 2004, at 3:23 PM, Richard Kenner wrote:

>     No it isn't.  You were doing mega dumps before tree-ssa merged,
>     back when Ada supposedly worked.
>
> Yes, to get caught up.  And then he did them daily.

You are still missing the point.
Daily is too often.
Every single individual patch should be submitted and committed 
separately.
Period.

Re: Ada mainline

[Robert Dewar]

Daniel Berlin wrote:

> You are still missing the point.
> Daily is too often.

Now I am puzzled, we make updates to the front end nearly
every day, and yet you think we should not contribute
patches with that frequency.

> Every single individual patch should be submitted and committed separately.
> Period.

It's not always clear what constitutes a "single individual patch".
We often do major reorganizations of the sources. These are represented
as a collection of individual patches, but I am not sure what you
would expect here.

Perhaps what would be helpful is to take one of the daily patches
that Arno did, and say exactly what you would have found helpful.
It will also be helpful to know if you are speaking as someone
expert in the Ada standard or not.

I assume for you a patch is all related changes. By the way, more than
half the patches are just collections of minor stylistic reformatting
(mostly done by me). These I would assume you have no objection to
batching, since they certainly don't require any discussion or review.

Re: Ada mainline

[Diego Novillo]

On Thu, 2004-09-09 at 23:04, Robert Dewar wrote:

> Now I am puzzled, we make updates to the front end nearly
> every day, and yet you think we should not contribute
> patches with that frequency.
> 
You contribute the patches at whatever frequency you want.  They get
independently approved at whatever frequency the reviewers approve
them.  Do I really have to explain such basic mechanisms to you?

> > Every single individual patch should be submitted and committed separately.
> > Period.
> 
> It's not always clear what constitutes a "single individual patch".
>
Have you read and understood http://gcc.gnu.org/contribute.html?  If
that doesn't answer your questions, we should probably add the missing
bits.

> We often do major reorganizations of the sources. These are represented
> as a collection of individual patches, but I am not sure what you
> would expect here.
> 
You should know.  Source reorgs have happened many times on gcc-patches.

> Perhaps what would be helpful is to take one of the daily patches
> that Arno did, and say exactly what you would have found helpful.
> It will also be helpful to know if you are speaking as someone
> expert in the Ada standard or not.
> 
Read http://gcc.gnu.org/contribute.html.


> I assume for you a patch is all related changes. By the way, more than
> half the patches are just collections of minor stylistic reformatting
> (mostly done by me). These I would assume you have no objection to
> batching, since they certainly don't require any discussion or review.
> 
Read http://gcc.gnu.org/contribute.html.  Do you know what the 'obvious
rule' is?


Diego.

Re: Ada mainline

[Joseph S. Myers]

On Thu, 9 Sep 2004, Diego Novillo wrote:

> > It's not always clear what constitutes a "single individual patch".
> >
> Have you read and understood http://gcc.gnu.org/contribute.html?  If
> that doesn't answer your questions, we should probably add the missing
> bits.

Also note that the principle of minimal individual patches is not new.  
It's something I moved from the manual to contribute.html.  The following 
are extracts from gcc.texi in GCC 2.2.2, and the principles apply just as 
much now as they did then:

# Send an explanation with your changes of what problem they fix or what
# improvement they bring about.  For a bug fix, just include a copy of the
# bug report, and explain why the change fixes the bug.

# Always include a proper bug report for the problem you think you have
# fixed.  We need to convince ourselves that the change is right before
# installing it.  Even if it is right, we might have trouble judging it if
# we don't have a way to reproduce the problem.

# Don't mix together changes made for different reasons.
# Send them @emph{individually}.

# If you make two changes for separate reasons, then we might not want to
# install them both.  We might want to install just one.  If you send them
# all jumbled together in a single set of diffs, we have to do extra work
# to disentangle them---to figure out which parts of the change serve
# which purpose.  If we don't have time for this, we might have to ignore
# your changes entirely.

# If you send each change as soon as you have written it, with its own
# explanation, then the two changes never get tangled up, and we can
# consider each one properly without any extra work to disentangle them.

# Ideally, each change you send should be impossible to subdivide into
# parts that we might want to consider separately, because each of its
# parts gets its motivation from the other parts.

# Send each change as soon as that change is finished.  Sometimes people
# think they are helping us by accumulating many changes to send them all
# together.  As explained above, this is absolutely the worst thing you
# could do.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada mainline

[Robert Dewar]

Hmm I just read Diego's entire response, and it seems to
amount to "the Ada patches should be handled the same
way as the C++ patches", but it doesn't say why. I also
didn't get an answer to my question of whether
Diego was speaking as a an Ada expert or Ada user (I
assume not), which I think is definitely relevant.

I really think that the Ada front end is quite different
from the C++ front end.

In the case of C++ we have large numbers of people
contributing patches which are then reviewed by
a small number of people.

In the case of the Ada front end we have a very
small number of people contributing all the patches
(this number is about 6-7), and this is the same
small group that approves these patches. Internally
our front end patch procedure is that one of these
6-7 people makes a change, discusses it among the
other 5-6 people if necessary (that's very rarely
necessary), and then checks the change against
our test suites (which include the public ACATS
tests, and also the very unpublic DEC tests, and
the AdaCore internal test suite). If there are no
regressions and the problem is fixed, or new
feature working, then the change is checked in
locally and reviewed by me (I still review all
Ada front end patches). If it all looks good,
it migrates into the FSF tree the next day or
so (if things are working smoothly), along with
the comments and revision history entries that
describe the fix. The RH entries incidentally
have a rather different style than the GCC
back end fixes, they are required to say *why*
the patch is being made, not just *what* was
done (which seems the more common style with
back end revision histories). There is also
a quite different level of commenting in the
sources for these changes.

The tasking run time is similarly handled,
except that the group of people involved
is even smaller in this case.

The back end fixes are handled in a very
different manner, following the standard
procedures as closely as we can.

Robert Dewar

Re: Ada mainline

[Richard Henderson]

On Thu, Sep 09, 2004 at 11:49:09PM -0400, Robert Dewar wrote:
> Hmm I just read Diego's entire response, and it seems to
> amount to "the Ada patches should be handled the same
> way as the C++ patches", but it doesn't say why.

Because that's what it means to cooperate with the gcc community.
Until you follow the rules -- that apply to everyone -- then you
are not part of the community.

If you want to do your own thing in your cloister, fine.  We're
not forcing you to be here.  But in that case I shouldn't think
you should expect any of the privledges or help that come from
being part of the community either.



r~

Re: Ada mainline

[Diego Novillo]

On Thu, 2004-09-09 at 23:49, Robert Dewar wrote:
> Hmm I just read Diego's entire response, and it seems to
> amount to "the Ada patches should be handled the same
> way as the C++ patches",
>            ^^^
             GCC

>  but it doesn't say why.
> 
I didn't want to insult your intelligence by stating the blatantly
obvious.  Robert, you seem to be a seasoned developer and should know
this, but since you seem confused, I will state the obvious: If you want
to contribute to project FOO, then you make sure that you follow the
guidelines set by the community developing FOO.


>  I also
> didn't get an answer to my question of whether
> Diego was speaking as a an Ada expert or Ada user (I
> assume not), which I think is definitely relevant.
> 
Neither.  I am just a GCC developer.  What's the relevance?  I will
probably never review an Ada patch more than superficially.  I'll
probably see them fly by on ada-patches or gcc-patches much like I see
most FE patches go by.

I just want to help you understand how GCC development works.  The
contribution model is orthogonal to the complexity of the particular
module that you are interested in contributing.

The importance of this to you, as an Ada user and developer, is that if
you don't follow these rules (and are unsuccessful in having them
changed) your module will probably be largely ignored by the rest of the
community.  So middle-end/back-end changes that happen to adversely
affect Ada will be met with a shrug and/or half-hearted attempts at
helping you out.

> I really think that the Ada front end is quite different
> from the C++ front end.
>
Irrelevant.  The Fortran front end is quite different from the Java
front end, which is quite different from the Objective-C front end.

> In the case of the Ada front end we have a very
> small number of people contributing all the patches
> (this number is about 6-7), and this is the same
> small group that approves these patches.
>
This is the case in several parts of GCC.  The procedure for patch
submission and approval is the same.

> feature working, then the change is checked in
> locally and reviewed by me (I still review all
> Ada front end patches). If it all looks good,
> it migrates into the FSF tree the next day or
> so
>
That is your mistake.  Post the individual patches, have them approved
by your internal maintainer and commit them individually.  Hell, the
approval can even be a mention of an offline approval by such and such
maintainer.  Have both the patch and the approval posted to the external
lists.

It's not hard.  We all do it.  All the time.  I am finding it
increasingly hard to explain these painfully obvious principles to you,
so I will just stop.  Go read contribute.html and then we can clarify
whatever questions you may have regarding patch submission and approval.


Diego.

Re: Ada mainline

[Robert Dewar]

Diego Novillo wrote:

> Neither.  I am just a GCC developer.  What's the relevance?  I will
> probably never review an Ada patch more than superficially.  I'll
> probably see them fly by on ada-patches or gcc-patches much like I see
> most FE patches go by.

I just wondered if you had looked at any of the GNAT front end
patches, or not.

Re: Ada mainline

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Hmm I just read Diego's entire response, and it seems to
| amount to "the Ada patches should be handled the same
| way as the C++ patches", but it doesn't say why. I also
| didn't get an answer to my question of whether
| Diego was speaking as a an Ada expert or Ada user (I
| assume not), which I think is definitely relevant.
| 
| I really think that the Ada front end is quite different
| from the C++ front end.

Is that a word from a C++ expert too?

Sorry, I could not resist.

The main point has been made by RTH.

-- Gaby

Re: Ada mainline

[Robert Dewar]

Gabriel Dos Reis wrote:

> Robert Dewar <dewar@gnat.com> writes:
> 
> | Hmm I just read Diego's entire response, and it seems to
> | amount to "the Ada patches should be handled the same
> | way as the C++ patches", but it doesn't say why. I also
> | didn't get an answer to my question of whether
> | Diego was speaking as a an Ada expert or Ada user (I
> | assume not), which I think is definitely relevant.
> | 
> | I really think that the Ada front end is quite different
> | from the C++ front end.
> 
> Is that a word from a C++ expert too?

Hmmm I don't think I need to be a C++ expert to see that
more people know C++ than Ada which is the point I was
making here.
> 
> Sorry, I could not resist.
> 
> The main point has been made by RTH.
> 
> -- Gaby

Re: Ada mainline

[Robert Dewar]

Bobby wrote:

> Robert Dewar wrote:

> Robert, My 3.5 on i686-pc-cygwin breaks in Ada.

The state of 3.5 for Ada is still very shakey. The
adaptation to Tree-SSA has been a major task that
Richard has been working on double full time for
quite a while now, and it is nearing getting to a
stable stage, but is still not there yet. For a
reasonably reliable Ada build at the moment, you
have to use 3.4.

Re: Ada mainline

[Robert Dewar]

Robert Dewar wrote:

> Bobby wrote:
> 
>> Robert Dewar wrote:
> 
> 
>> Robert, My 3.5 on i686-pc-cygwin breaks in Ada.
> 
> 
> The state of 3.5 for Ada is still very shakey. The
> adaptation to Tree-SSA has been a major task that
> Richard has been working on double full time for
> quite a while now, and it is nearing getting to a
> stable stage, but is still not there yet. For a
> reasonably reliable Ada build at the moment, you
> have to use 3.4.

By the way, it's 1am in Paris where I am, and I
will likely not be online again for a while, so
please don't take my sudden absence as other than
the need to sleep and rush around tomorrow :-)

Robert
> 
> 

Re: Ada mainline

[Richard Henderson]

On Fri, Sep 10, 2004 at 12:51:58AM -0400, Robert Dewar wrote:
> For a reasonably reliable Ada build at the moment, you
> have to use 3.4.

No, you have to go back to 3.3.  No 3.4 version has worked
for me for *any* target.


r~

Re: Ada mainline

[Robert Dewar]

Richard Henderson wrote:

> No, you have to go back to 3.3.  No 3.4 version has worked
> for me for *any* target.

That's strange, to be investigated ...

Re: Ada mainline

[Laurent GUERBY]

On Fri, 2004-09-10 at 07:09, Robert Dewar wrote:
> Richard Henderson wrote:
> 
> > No, you have to go back to 3.3.  No 3.4 version has worked
> > for me for *any* target.
> 
> That's strange, to be investigated ...

It has been investigated, I submitted in a hurry one "kludge" patch
for 3.4.2 (I did not know about the problem until the days before the
release as I've been using 3.3 to bootstrap) but unfortunately it broke
parallel build on all platforms, I suggested a change to the patch to
solve this problem, but Arnaud refused it on stylistic grounds without
proposing an alternative to my knowledge.

FSF GCC 3.4.0, 3.4.1 and 3.4.2 are unable to recompile
themselves once installed on x86_64 and other 64 bits target 
(and if IIRC mainline too), which is quite bad.

Laurent

Re: Ada mainline

[Robert Dewar]

Diego Novillo wrote:

> Have you read and understood http://gcc.gnu.org/contribute.html?  If
> that doesn't answer your questions, we should probably add the missing
> bits.

Yes, of course I have read this, but the entire premise here is of an
extended community of developers submitting patches to a small group
of people to be reviewed.

Re: Ada mainline

[Kaveh R. Ghazi]

 > From: Robert Dewar
 >  > Diego Novillo wrote:
 >  > 
 >  > 
 >  > Have you read and understood http://gcc.gnu.org/contribute.html?  If
 >  > that doesn't answer your questions, we should probably add the missing
 >  > bits.
 > 
 > Yes, of course I have read this, but the entire premise here is of an
 > extended community of developers submitting patches to a small group
 > of people to be reviewed.

As I mentioned here http://gcc.gnu.org/ml/gcc/2004-09/msg00468.html
there are other reasons for following our rules besides the explicit
approve/reject scenario by an existing guru.

Reasons include:

1.  You often get helpful suggestions.
2.  You help create/educate the next generation of developers.
3.  There is a public audit trail and discussion for posterity.

You might not believe #1 can happen for Ada.  That's true mostly
because your cloistered developement model means #2 and #3 can't
happen today.  So only the handful of current ACT employees can ever
touch GNAT.  If that's your goal, then you've been wildly successful.
But that model IMHO is ultimately self-defeating for both GNAT and
ACT.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Ada mainline

[Manfred Hollstein]

On Fri, 10 Sep 2004, 01:23:16 +0200, Kaveh R. Ghazi wrote:
>  > From: Robert Dewar
>  >  > Diego Novillo wrote:
>  >  > 
>  >  > 
>  >  > Have you read and understood http://gcc.gnu.org/contribute.html?  If
>  >  > that doesn't answer your questions, we should probably add the missing
>  >  > bits.
>  > 
>  > Yes, of course I have read this, but the entire premise here is of an
>  > extended community of developers submitting patches to a small group
>  > of people to be reviewed.
> 
> As I mentioned here http://gcc.gnu.org/ml/gcc/2004-09/msg00468.html
> there are other reasons for following our rules besides the explicit
> approve/reject scenario by an existing guru.
> 
> Reasons include:
> 
> 1.  You often get helpful suggestions.
> 2.  You help create/educate the next generation of developers.
> 3.  There is a public audit trail and discussion for posterity.
> 
> You might not believe #1 can happen for Ada.  That's true mostly
> because your cloistered developement model means #2 and #3 can't
> happen today.  So only the handful of current ACT employees can ever
> touch GNAT.  If that's your goal, then you've been wildly successful.
> But that model IMHO is ultimately self-defeating for both GNAT and
> ACT.

This discussion actually reminds me _a lot_ of the way gcc development
worked _before egcs started_... ;-) We all know who controlled the
gcc2 development, and why egcs was the only solution to get around it.

If AdaCore does not appreciate that people from the community are
actually willing to work on the same beast by providing patches, I'm
afraid (a) GNAT remains in such a shaky shape all the time, or (b) it
will most likely be dropped again from the FSF tree. If we don't get
a mutual agreement on how patches have to be submitted, I'd prefer to
see (b) happen, although I have a long history with Ada... sigh.

Cheers.

l8er
manfred

Re: Ada mainline

[Daniel Berlin]

On Sep 9, 2004, at 11:04 PM, Robert Dewar wrote:

> Daniel Berlin wrote:
>
>> You are still missing the point.
>> Daily is too often.
>
> Now I am puzzled, we make updates to the front end nearly
> every day, and yet you think we should not contribute
> patches with that frequency.

Now you've just taken what i said out of context in order to twist my 
words.
I said "daily is too often" in the context of how often arno was 
dumping patches into the mainline.

I'm not going to get into a discussion about a topic so obvious that 
everyone but you guys seem to get it.  I'm starting to feel like you 
guys are being deliberately obtuse about this.
Thus, i'm extricating myself from this discussion.

Re: Ada mainline

[Robert Dewar]

Daniel Berlin wrote:

> Now you've just taken what i said out of context in order to twist my 
> words.
> I said "daily is too often" in the context of how often arno was dumping 
> patches into the mainline.

OK, but I am still not quite following whether you think he is dumping
too frequently or too infrequently. What we aim at is day by day
synchronization of the sources. As Arno noted, we have not been able
to do this recently, since we can't meet the criterion of ensuring
that the bootstrap is not broken, if it is broken to start with.

Re: Ada mainline

[Diego Novillo]

On Thu, 2004-09-09 at 23:54, Robert Dewar wrote:
> Daniel Berlin wrote:
> 
> > Now you've just taken what i said out of context in order to twist my 
> > words.
> > I said "daily is too often" in the context of how often arno was dumping 
> > patches into the mainline.
> 
> OK, but I am still not quite following whether you think he is dumping
> too frequently or too infrequently. What we aim at is day by day
> synchronization of the sources. As Arno noted, we have not been able
> to do this recently, since we can't meet the criterion of ensuring
> that the bootstrap is not broken, if it is broken to start with.
> 
And what you are still unable to grasp is the basic point that dumping
your internal repository into the FSF tree does not meet the
requirements set in contribute.html.

"Day by day synchronization of the sources" is not acceptable to the GCC
community.


Diego.

Re: Ada mainline

[Richard Kenner]

    If a non-confidential synthetic testcase suitable for the lists and
    the public testsuite cannot be constructed, you need to go to that
    much more effort to be sure the explanation is absolutely clear.

I do think that people at ACT understand this.  The question is basically
where is the time to do that "extra effort" going to come from.  As Robert
said earlier today, that's something that will take a lot of discussion
with the people involved.

Re: Ada mainline

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     If a non-confidential synthetic testcase suitable for the lists and
|     the public testsuite cannot be constructed, you need to go to that
|     much more effort to be sure the explanation is absolutely clear.
| 
| I do think that people at ACT understand this.  The question is basically
| where is the time to do that "extra effort" going to come from.

This is a general problem many people have been faceing for long time.
Why do you believe ACT is exempted? 

| As Robert
| said earlier today, that's something that will take a lot of discussion
| with the people involved.

-- Gaby

Re: Ada mainline

[Richard Kenner]

    Reasons include:

    1.  You often get helpful suggestions.
    2.  You help create/educate the next generation of developers.
    3.  There is a public audit trail and discussion for posterity.

But what I fail to understand is why there is such a significant
difference between Arno checking in patches in a daily batch and
individuals each doing the work in terms of the above.

The patches are visible in both cases, so there's no difference with
respect to #1 and #2.  As to #3, see my response to RTH: either such
discussions don't exist or they can't be made public in real-time due
to the proprietary nature of the bug report.

Re: Ada mainline

[Robert Dewar]

Thanks to everyone who has participated in the discussion
in this thread. We will have a discussion at AdaCore and
see if we can come up with a mode of working that will
fit more comfortably with the needs of gcc developers.

Robert Dewar

Re: Ada mainline

[Joseph S. Myers]

On Thu, 9 Sep 2004, Richard Kenner wrote:

> The patches are visible in both cases, so there's no difference with
> respect to #1 and #2.  As to #3, see my response to RTH: either such
> discussions don't exist or they can't be made public in real-time due
> to the proprietary nature of the bug report.

So provide the detailed explanation afterwards, with the patch.  Look at 
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01641.html>.  This suffers 
from the problems of a proprietary testcase, in a proprietary testsuite, 
for a problem in reload, which only shows the problem with 3.3 and 3.4 
because of the tree optimisers.  Any one of these might make providing a 
public testcase difficult or impossible.  But it includes a detailed 
explanation, longer than the patch, which both helps understand the 
problem and might also help people unfamiliar with reload to learn about 
it.  If a non-confidential synthetic testcase suitable for the lists and 
the public testsuite cannot be constructed, you need to go to that much 
more effort to be sure the explanation is absolutely clear.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada mainline

[James A. Morrison]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Reasons include:
> 
>     1.  You often get helpful suggestions.
>     2.  You help create/educate the next generation of developers.
>     3.  There is a public audit trail and discussion for posterity.
> 
> But what I fail to understand is why there is such a significant
> difference between Arno checking in patches in a daily batch and
> individuals each doing the work in terms of the above.

 Three reasons.  Large patches are harder to understand than small patches.
Combined patches make it harder to figure out what one patch fixes/changes.
And, gzipped attachments aren't automagically opened in my mail reader.
 
> The patches are visible in both cases, so there's no difference with
> respect to #1 and #2.  As to #3, see my response to RTH: either such
> discussions don't exist or they can't be made public in real-time due
> to the proprietary nature of the bug report.
> 


-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: Ada mainline

[D. Starner]

> In fact if you want to look at any of the front end patches,
> and if you *do* know the Ada standard (and relevant AI's)
> well, you should find them quite easy to understand, since
> they are very well documented. However, the group of people
> that meet this criterion is small (and most of them work
> for AdaCore, and most of the rest work for AdaCore's
> competitors :-)

I get the impression that ACT feels that no one else wants to  
work on GNAT, that no one is capable of working on GNAT without
all of ACT's proprietary test suites and everything, and that
the concerns and problems of users who don't have a contract
with ACT are without interest. I'm certainly not motivated to
start working on GNAT, given that ACT is likely to be reviewing
my patches.
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: Ada mainline

[Robert Dewar]

D. Starner wrote:

> I get the impression that ACT feels that no one else wants to  
> work on GNAT, that no one is capable of working on GNAT without
> all of ACT's proprietary test suites and everything, and that
> the concerns and problems of users who don't have a contract
> with ACT are without interest. I'm certainly not motivated to
> start working on GNAT, given that ACT is likely to be reviewing
> my patches.

I certainly did not mean to say that we won't review patches.
We have received a few patches from customers, and we most
certainly look at them, and we certainly intend to review
any GNAT patches that people submit. I would guess that it
is relatively unlikely that people will submit patches for
the front end, although it is certainly very easy to get into
the GNAT front end if you know Ada (our experience is for
example that it is far easier for students to modify the
GNAT front end than the gcc back end).

The test suites help, but really aren't necessary for doing
work on the front end (certainly the compiler students at
NYU who modify the front end for a semester project don't
use them). In practice, running the ACATS suite is pretty
good (the ACATS suite is certainly more comprehensive than
any publically available suite for C or C++ for example).
As part of our review of any patch, we most certainly
would run the DEC Test suite and our proprietary test
suite, but you don't need that to do fixes, improvements
etc.

It's not that problems and concerns of users who don't
have a contract with ACT are without interest, it is
simply that they have a far lower priority. The people
who do have contracts support the several dozen full
time engineers working on GNAT, so that is a natural
assignment of priority. We have in fact incorporated
a significant number of patches to GNAT from FSF,
though they have mostly been of things in the obvious
category.

Re: Ada mainline

[Florian Weimer]

* Robert Dewar:

> I certainly did not mean to say that we won't review patches.
> We have received a few patches from customers, and we most
> certainly look at them, and we certainly intend to review
> any GNAT patches that people submit.

So far, there were only very brief periods of time during which FSF
mainline was in a good shape (based on ACATS and other tests) *and*
relatively close to AdaCore's internal tree.  Unless both conditions
are fulfilled, it's difficult to reach something that can actually be
submitted as a patch.

For example, my conservative GC patch[1] was overtaken by your
internal development (which was, at that time, mostly invisible as the
FSF tree wasn't updated).  What's worse, you made an implementation
detail of the run-time library public, which I had changed. 8-(

One day, I will try again, but this makes only sense if I don't have
to work from stale sources (either because the trees aren't in sync,
or the FSF tree doesn't even bootstrap).  And I've learned that bit of
coordination in advance is necessary, too.

> I would guess that it is relatively unlikely that people will submit
> patches for the front end, although it is certainly very easy to get
> into the GNAT front end if you know Ada

Indeed it's not too hard.  The inline documentation and GNAT's
cross-referencing tools are very helpful.


1. Based on the Boehm collector, with support for pragma Controlled
and Finalize_Storage_Only, and (mostly) correct classification of
pointer-free storage.  No, it didn't handle packed records correctly.
But tasking should have worked. -- All in all, it's almost in the
"obvious" category, but not completely. 8-)

Re: Ada mainline

[Paul Koning]

>>>>> "D" == D Starner <shalesller@writeme.com> writes:

 >> In fact if you want to look at any of the front end patches, and
 >> if you *do* know the Ada standard (and relevant AI's) well, you
 >> should find them quite easy to understand, since they are very
 >> well documented. However, the group of people that meet this
 >> criterion is small (and most of them work for AdaCore, and most of
 >> the rest work for AdaCore's competitors :-)

 D> I get the impression that ACT feels that no one else wants to work
 D> on GNAT, that no one is capable of working on GNAT without all of
 D> ACT's proprietary test suites and everything, and that the
 D> concerns and problems of users who don't have a contract with ACT
 D> are without interest. I'm certainly not motivated to start working
 D> on GNAT, given that ACT is likely to be reviewing my patches. 

I had a similar reaction. 

I'll just speak up one time, as an occasional GCC contributor not all
that skilled yet in the broader GCC.

My reading of the arguments for the Ada unique process is "there are
only three people who care about this stuff anyway, so why follow the
standard process".

This is a self-fulfilling argument.  By operating a closed process,
you exclude the possibility of others becoming involved.  Conversely,
by changing to the standard open process, the number of interested and
qualified people will probably grow over time, which is to everyone's
benefit. 

	 paul

Re: Ada mainline

[Matt Austern]

On Sep 10, 2004, at 7:11 AM, Paul Koning wrote:

>>>>>> "D" == D Starner <shalesller@writeme.com> writes:
>
>>> In fact if you want to look at any of the front end patches, and
>>> if you *do* know the Ada standard (and relevant AI's) well, you
>>> should find them quite easy to understand, since they are very
>>> well documented. However, the group of people that meet this
>>> criterion is small (and most of them work for AdaCore, and most of
>>> the rest work for AdaCore's competitors :-)
>
>  D> I get the impression that ACT feels that no one else wants to work
>  D> on GNAT, that no one is capable of working on GNAT without all of
>  D> ACT's proprietary test suites and everything, and that the
>  D> concerns and problems of users who don't have a contract with ACT
>  D> are without interest. I'm certainly not motivated to start working
>  D> on GNAT, given that ACT is likely to be reviewing my patches.
>
> I had a similar reaction.
>
> I'll just speak up one time, as an occasional GCC contributor not all
> that skilled yet in the broader GCC.
>
> My reading of the arguments for the Ada unique process is "there are
> only three people who care about this stuff anyway, so why follow the
> standard process".
>
> This is a self-fulfilling argument.  By operating a closed process,
> you exclude the possibility of others becoming involved.  Conversely,
> by changing to the standard open process, the number of interested and
> qualified people will probably grow over time, which is to everyone's
> benefit.

What it really comes down to is a question: are the people who work
on Ada happy with the current state of affairs?

My impression of the current state of affairs with Ada and GCC: Ada
is a second-class citizen.  Other than the handful of people who work
on the Ada front end, nobody in the GNU community cares much about
it.  Very few GNU developers even build the Ada front end, let alone
test it.  Many don't even know whether it can be built on their 
platforms.
Nobody cares much if a bug breaks Ada (unlike C++ or ObjC or Java),
and Ada quality isn't considered in release criteria.  Most GCC
developers just ignore Ada, and they don't mind it as long as it doesn't
affect their lives.

So: if the people who work on the Ada front end are happy with that
state of affairs, they probably don't have to change the way they work.
If they aren't happy with it, if they want Ada to become a first-class
member of the GNU Compiler Collection, then they should think about
what it'll take to get there.

			--Matt

Re: Ada mainline

[Richard Kenner]

+===========================GNAT BUG DETECTED==============================+
| 3.5.0 20040908 (experimental) (i686-pc-linux-gnu) GCC error:             |
| in peel_address, at tree-ssa-loop-ivopts.c:2560                          |
| Error detected at a-exexda.adb:312:8                                     |

The fix for this one is obvious, but it's waiting on the larger issue of
whether or not peel_address should use get_inner_reference.

../../xgcc -B../../ -c -g -O2 -fPIC      -W -Wall -gnatpg  a-nllcef.ads -o a-nllcef.o
+===========================GNAT BUG DETECTED==============================+
| 3.5.0 20040908 (experimental) (x86_64-unknown-linux-gnu) GCC error:      |
| in optimize_mode_switching, at lcm.c:1225                                |
| Error detected at a-ngcefu.adb:710:1 [a-nllcef.ads:19:1]                 |

I've been mentioning this since Saturday.  There's some PR that it is
likely related to, but I forgot the number.

There are also a few others I'm seeing, but they may be related to kludges
I've put into my tree to get around these so I'm waiting for these to
get fixed before spending too much time on the others.

Re: Ada mainline

[Arnaud Charlet]

> +===========================GNAT BUG DETECTED==============================+
> | 3.5.0 20040908 (experimental) (i686-pc-linux-gnu) GCC error:             |
> | in peel_address, at tree-ssa-loop-ivopts.c:2560                          |
> | Error detected at a-exexda.adb:312:8                                     |
> 
> The fix for this one is obvious, but it's waiting on the larger issue of
> whether or not peel_address should use get_inner_reference.

Well, this one is really blocking me at this stage, so I'd really appreciate
a quick fix/hack/resolution on it.

Arno

Re: Ada mainline

[Jan Hubicka]

> > +===========================GNAT BUG DETECTED==============================+
> > | 3.5.0 20040908 (experimental) (i686-pc-linux-gnu) GCC error:             |
> > | in peel_address, at tree-ssa-loop-ivopts.c:2560                          |
> > | Error detected at a-exexda.adb:312:8                                     |
> > 
> > The fix for this one is obvious, but it's waiting on the larger issue of
> > whether or not peel_address should use get_inner_reference.
> 
> Well, this one is really blocking me at this stage, so I'd really appreciate
> a quick fix/hack/resolution on it.

I will commit the patch adding the extra case to old implementatino as
obvious then.

Honza
> 
> Arno

Re: Ada mainline

[Arnaud Charlet]

> I will commit the patch adding the extra case to old implementatino as
> obvious then.

Thanks, I really appreciate that.

Generally speaking, if simple changes (even if not complete or perfect)
fixing such Ada breakages could be put in place rapidly, that would
be a big help.

Arno

Re: Ada mainline

[Jan Hubicka]

> > I will commit the patch adding the extra case to old implementatino as
> > obvious then.
> 
> Thanks, I really appreciate that.
> 
> Generally speaking, if simple changes (even if not complete or perfect)
> fixing such Ada breakages could be put in place rapidly, that would
> be a big help.

I've commited it then.
Are there any other problems in Ada pending from my side?

Honza
> 
> Arno

Re: Ada mainline

[Paolo Bonzini]

> Generally speaking, if simple changes (even if not complete or perfect)
> fixing such Ada breakages could be put in place rapidly, that would
> be a big help.

I don't agree.  This may be the case if ACT people worked and committed 
changes directly to the FSF tree but IMHO it is not, given the way Ada 
commits are made.  Such fixes should be only posted to 
gcc-patches@gcc.gnu.org so that you can put them into your private trees 
(like Kenner seems to be doing), and we do not risk leaving hacks 
indefinitely in the FSF mainline.

Paolo

Re: Ada mainline

[Paolo Bonzini]

> Generally speaking, if simple changes (even if not complete or perfect)
> fixing such Ada breakages could be put in place rapidly, that would
> be a big help.

I don't agree.  This may be the case if ACT people worked and committed 
changes directly to the FSF tree but IMHO it is not, given the way Ada 
commits are made.  Such fixes should be only posted to 
gcc-patches@gcc.gnu.org so that you can put them into your private trees 
(like Kenner seems to be doing), and we do not risk leaving hacks 
indefinitely in the FSF mainline.

Paolo

Re: Ada mainline

[Arnaud Charlet]

> I don't agree.  This may be the case if ACT people worked and committed 
> changes directly to the FSF tree but IMHO it is not, given the way Ada 
> commits are made.  Such fixes should be only posted to 

That would not make any difference, except that it would be worse, since
more people would be annoyed at FSF tree breaking Ada.

> gcc-patches@gcc.gnu.org so that you can put them into your private trees 
> (like Kenner seems to be doing), and we do not risk leaving hacks 
> indefinitely in the FSF mainline.

Trouble with this approach is that *nobody* can build Ada out of the box,
which is very annoying. Having only me or Richard being able to build Ada
isn't that useful. I'd rather have as much people being able to build Ada,
that's the only way to avoid these continuous breakages.

Arno

Re: Ada mainline

[Arnaud Charlet]

> Trouble with this approach is that *nobody* can build Ada out of the box,
> which is very annoying. Having only me or Richard being able to build Ada
> isn't that useful. I'd rather have as much people being able to build Ada,
> that's the only way to avoid these continuous breakages.

Plus the fact that it's very time concuming *and* error-prone to maintain
these private patches, and then we don't really know what we are testing,
nor is it easy to know when a failure occurs whether it's due to local
changes, or new updates, or the changes being tested.

Really, having Ada broken, and then no fix or revert for days is not
a workable situation in practice.

Arno

Re: Ada mainline

[Diego Novillo]

On Thu, 2004-09-09 at 09:13, Arnaud Charlet wrote:

> Generally speaking, if simple changes (even if not complete or perfect)
> fixing such Ada breakages could be put in place rapidly, that would
> be a big help.
> 
Why should we?  You folks like to do mega dumps of your local trees,
instead of following the usual patch posting and committing procedures. 
That's probably the single most frustrating aspect I find regarding Ada
in the FSF tree.


Diego.

Re: Ada mainline

[Arnaud Charlet]

> Why should we?  You folks like to do mega dumps of your local trees,
> instead of following the usual patch posting and committing procedures. 
> That's probably the single most frustrating aspect I find regarding Ada
> in the FSF tree.

Let's please not start non constructive discussion: it's a chicken and
egg problem.

The only reason I am doing "mega dumps" is because it's almost impossible
to build Ada daily.

I was doing updates much more frequently being tree-ssa, but instead of
being able to improve things, I could only get into a very
degraded mode (although I can assure you that the changes are very well
tested even before being considered for inclusion in the FSF tree,
and all tested separately, so these changes are typically very safe).

Arno

Re: Ada mainline

[Richard Henderson]

On Thu, Sep 09, 2004 at 03:50:53PM +0200, Arnaud Charlet wrote:
> Let's please not start non constructive discussion: it's a chicken and
> egg problem.

No it isn't.  You were doing mega dumps before tree-ssa merged,
back when Ada supposedly worked.


r~

Ada mainline

[Laurent GUERBY]

I've seen various patches and emails exchanged, but it looks like
mainline does not currenctly bootstrap with Ada, is anyone
working on those problems? I can submit gdb traces / variables / test patches
if needed (after 18:00 GMT when I'm back from work).

Laurent

LAST_UPDATED
Thu Sep  9 00:23:49 CEST 2004
Wed Sep  8 22:23:49 UTC 2004

stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/install-20040909T003617/i686-pc-linux-gnu/bin/ -c -g -O2      -gnatpg -gnata -g -O1 -fno-inline \
 -I- -I. -Iada -I/home/guerby/work/gcc/version-head/gcc/ada /home/guerby/work/gcc/version-head/gcc/ada/a-except.adb -o ada/a-except.o
+===========================GNAT BUG DETECTED==============================+
| 3.5.0 20040908 (experimental) (i686-pc-linux-gnu) GCC error:             |
| in peel_address, at tree-ssa-loop-ivopts.c:2560                          |
| Error detected at a-exexda.adb:312:8                                     |

../../xgcc -B../../ -c -g -O2 -fPIC      -W -Wall -gnatpg  a-nllcef.ads -o a-nllcef.o
+===========================GNAT BUG DETECTED==============================+
| 3.5.0 20040908 (experimental) (x86_64-unknown-linux-gnu) GCC error:      |
| in optimize_mode_switching, at lcm.c:1225                                |
| Error detected at a-ngcefu.adb:710:1 [a-nllcef.ads:19:1]                 |

Re: Ada mainline

[Giovanni Bajo]

Laurent GUERBY wrote:

> stage1/xgcc -Bstage1/
>  -B/home/guerby/work/gcc/install/install-20040909T003617/i686-pc-linux-gnu/bi
n/
> -c -g -O2      -gnatpg -gnata -g -O1 -fno-inline \ -I- -I. -Iada
> -I/home/guerby/work/gcc/version-head/gcc/ada
> /home/guerby/work/gcc/version-head/gcc/ada/a-except.adb -o
> ada/a-except.o +===========================GNAT BUG
> DETECTED==============================+
>> 3.5.0 20040908 (experimental) (i686-pc-linux-gnu) GCC error:
>> |
>> in peel_address, at tree-ssa-loop-ivopts.c:2560
>> |
>> Error detected at a-exexda.adb:312:8
>> |

This is bcause peel_address does not handle some trees generated by Ada (I
think it was VIEW_CONVERT_EXPR, but I may be wrong). Honza was working on it,
but then he preferred to wait for Zdenek to be back. Bootstrapping
with -fno-ivopts should be a workaround for now.


> ../../xgcc -B../../ -c -g -O2 -fPIC      -W -Wall -gnatpg
> a-nllcef.ads -o a-nllcef.o +===========================GNAT BUG
> DETECTED==============================+
>> 3.5.0 20040908 (experimental) (x86_64-unknown-linux-gnu) GCC error:
>> |
>> in optimize_mode_switching, at lcm.c:1225
>> |
>> Error detected at a-ngcefu.adb:710:1 [a-nllcef.ads:19:1]
>> |

This is PR 17345. It was broken by Uros i387 patch, and Honza has a proposed
solution. See the audit trail for more infos. You may want to double-check that
the attacched patch does indeed cure the Ada failure as well.

Giovanni Bajo