Re: GCC2 merging (was "native language support now available")

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    Correct.  So if gcc2 were more reliable than egcs, that would be an
    argument in its favor.  Is it?

There's no way to know, because there's no good way of measuring reliability;
it's not at all simply a matter of the number of bugs.

    The answer, unfortunately, is that it is not.  The reason is that egcs
    has not only been more successful in recruiting developers, but also
    in recruiting testers and in doing tests in a consistent manner.

You mean overall testing.  People in the software engineering community often
say that such testing isn't very valuable.  The kind of testing that's the
most important in producing high reliability software is *unit testing*,
which means testing each function individually to make sure it meets its
specifications under all conditions.  As far as I know, this is not done for
either gcc2 or egcs.

An interesting exercise would be to look at the ISO 9000 standard and see if
either project meets it and to try to figure out what SEI level each project
has.

It is possible to derive *some* information from bugs, but what you have to
look at is not the number of bugs but the nature of each in detail.  I'm not
that familiar with the work that's been done in that area.

Re: GCC2 merging (was "native language support now available")

[joel]

On Tue, 13 Oct 1998, Richard Kenner wrote:

> You mean overall testing.  People in the software engineering community often
> say that such testing isn't very valuable.  The kind of testing that's the
> most important in producing high reliability software is *unit testing*,
> which means testing each function individually to make sure it meets its
> specifications under all conditions.  As far as I know, this is not done for
> either gcc2 or egcs.

I agree with this.  But from a practical viewpoint, frequently running 
regression tests on a variety of host/targets is important even if you
have unit tests.

It is also difficult to build up unit tests on a large body of software
after the fact.   I think it would be nice if such tests existed and could
be run automatically but unfortunately they do not exist today.

> An interesting exercise would be to look at the ISO 9000 standard and see if
> either project meets it and to try to figure out what SEI level each project
> has.

I think it would be interesting to see how these standards could be
applied to such a distributed, volunteer based development effort.  There
are certainly benefits to ISO 9000 and SEI levels.  Both require some
administrative infrastructure and controls which would be challenging to
have in a distributed environment.  Interesting.

> It is possible to derive *some* information from bugs, but what you have to
> look at is not the number of bugs but the nature of each in detail.  I'm not
> that familiar with the work that's been done in that area.

Yes.  If you get 12 reports of the same bug, only one good test case
should enter the regression tests.

On a related note, bugs should be tracked by subsystem or module so a
piece of the implementation with high defect rates can be redesigned.
I have seen a handful of articles which claim this type analysis and
replacement of problem code can be highly beneficial.

--joel

Re: GCC2 merging (was "native language support now available")

[Ben Scherrey]

Richard Kenner wrote:
> An interesting exercise would be to look at the ISO 9000 standard and see if
> either project meets it and to try to figure out what SEI level each project
> has.

	Is this a serious suggestion? No GNU project that I know of would even
begin to qualify for either. This is actually one of my biggest problems
with these efforts. You have to be so deep into the source code of the
product before you can even begin to consider participating in the
development on any substantial basis. When I do software development, I
don't write a line of code until I've got a good overall design on how
its going to work. This simply doesn't exist.

	regards,

		Ben Scherrey

Re: GCC2 merging (was "native language support now available")

[Matthias Urlichs]

  kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> 
> say that such testing isn't very valuable.  The kind of testing that's the
> most important in producing high reliability software is *unit testing*,
> which means testing each function individually to make sure it meets its
> specifications under all conditions.  As far as I know, this is not done for
> either gcc2 or egcs.
> 
IMHO it's difficult if not impossible to verify gcc this way. Just look at
the bugs squashed during egcs-1.1 development. Many of them only surfaced
under very specific circumstances and the test programs frequently are
twenty lines of C, all important to trigger the bug.

Mind you, I don't have a better answer either...

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Q:  How many astronomers does it take to change a light bulb?
A:  None.  Astronomers prefer the dark.

Re: GCC2 merging (was "native language support now available")

[Richard Earnshaw]

>   kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> > 
> > say that such testing isn't very valuable.  The kind of testing that's the
> > most important in producing high reliability software is *unit testing*,
> > which means testing each function individually to make sure it meets its
> > specifications under all conditions.  As far as I know, this is not done for
> > either gcc2 or egcs.
> > 
> IMHO it's difficult if not impossible to verify gcc this way. Just look at
> the bugs squashed during egcs-1.1 development. Many of them only surfaced
> under very specific circumstances and the test programs frequently are
> twenty lines of C, all important to trigger the bug.
> 
> Mind you, I don't have a better answer either...
> 

The problem lies in the fact that an optimizing compiler works by 
performing a series of transforms on its input.  These transforms are 
piled on top of each other, so transforms performed later in the 
compilation will be done differently depending on earlier transforms.  
Trying to reliably test, say, the reload pass by using a C source file is 
a nightmare, since small changes to earlier transforms can completely 
change the behaviour of the reload pass.

One solution *might* be to have an RTL reader in the compiler along with 
flags to make it just run particular passes of the compiler -- but even 
that wouldn't be easy because rtl dumps don't currently contain the 
complete meta data for the compilation.

RE: GCC2 merging (was "native language support now available")

[James Mansion]

> From: Richard Stallman [ mailto:rms@gnu.org ]
>     How do you propose to progress this - is there even a real issue
>     beyond turf war?
> 
> I'm open to having the EGCS team become the GCC maintainers
> and making EGCS the official version of GCC.
> 

I suspect that in the end that may be pretty much forced.

But, given that there is one project that is supposed to be very stable,
and another that is supposed to be experimental, would it be possible to
take a hybrid approach?

Suppose that 'gcc' picked up stable egcs releases (eg the 1.1 release)
but was not impacted by the development tips on egcs?

If kenner's objections are essentially related to 'stability' and
the management of the process, then it seems (perhaps naively)
that it should be possible to define acceptance criteria in terms
of test cases and formal regression tests and win all round.  It
does have to be the case that any delay in taking the egcs team's
view of what constitutes a stable release over to gcc would need
to be managed by a public process, or the PR situation will not
improve at all.  If lack of documentation is a problem, then that
would be fair and I suspect that it might actually force the pace
here in a positive way.

Of course, no-one I know particularly likes to have a task that is
'just maintenance'.  But this would make 'gcc' essentially an
acceptance management process, and I'd guess that if bugs have been
found then there would be volunteers to integrate and test fixes
that might otherwise have been made to the egcs tree only.

James

(yeah - and can we *please* review the LGPL?  It does not seem to
make any practical sense for template systems or C++ inlines in
general.)

Re: GCC2 merging (was "native language support now available")

[Joe Buck]

> PS: What do we do about the pgcc split? Ask them to combine their stuff
> with egcs to become the *one* true gcc? I'd like to see their Pentium
> optimizations included. 

The egcs maintainers are working with some of the pgcc people to get
things merged; it's been slower going than expected though.  The current
status is that pgcc is egcs plus diffs.  I hope that those diffs will
eventually approach zero.  Even the pgcc people will tell you that the way
some things were done isn't the best way.

> Frankly, it makes me nervous to see the various pgcc/egcs/gcc 2.8.x trees
> split from gcc 2.7.2.

These splits preceded egcs (there was pgcc, there are the Cygnus releases
to their customers, as well as a couple of others).  One of the initial
egcs goals was to reduce the number of forks.

Re: GCC2 merging (was "native language support now available")

[Marc Espie]

In article < Pine.LNX.4.05.9810132222560.1533-100000@tahallah.demon.co.uk > you write:

>PS: What do we do about the pgcc split? Ask them to combine their stuff
>with egcs to become the *one* true gcc? I'd like to see their Pentium
>optimizations included. 

The problem with the pgcc-split is that not all the world revolves around
Intel... I think that the idea was that nobody really likes that split,
but it has to be resolved practically, mainly, clean up stuff so that the
pentium-specific hacks don't invade the main compiler, and make it impossible
to compile/use/maintain gcc on anything but a pentium...

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    > An interesting exercise would be to look at the ISO 9000 standard and
    > see if either project meets it and to try to figure out what SEI level
    > each project has.

    Is this a serious suggestion?

Just as a thought exercise.  Actually obtaining the ratings would be quite
expensive even if it did qualify.

    No GNU project that I know of would even begin to qualify for
    either.

That's my sense too, but I think it would be very illuminating for
many people to see precisely *why* they won't since these are issues I
suspect most people don't think about much.

    This is actually one of my biggest problems with these efforts. You
    have to be so deep into the source code of the product before you can
    even begin to consider participating in the development on any
    substantial basis. When I do software development, I don't write a
    line of code until I've got a good overall design on how its going to
    work. This simply doesn't exist.

Right.  That was my comment yesterday: I think the major thing missing
from GCC is good internal documentation, saying precisely what the
interface to each function is, including what assumptions it makes
about its input.

Re: GCC2 merging (was "native language support now available")

[Alex Buell]

On Tue, 13 Oct 1998, Richard Stallman wrote:

> I'm open to having the EGCS team become the GCC maintainers and making
> EGCS the official version of GCC.

Good idea! Then we can end this now and get on with our EGCS-enriched
lives. :o)

PS: What do we do about the pgcc split? Ask them to combine their stuff
with egcs to become the *one* true gcc? I'd like to see their Pentium
optimizations included. 

Frankly, it makes me nervous to see the various pgcc/egcs/gcc 2.8.x trees
split from gcc 2.7.2. It's time we stopped this and recombined the three
into one unified compiler system. 

PPS: I salute you, as the founder of the Free Software lifestyle. 

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.125 #49 SMP Fri Oct 9 07:18:02 EDT 1998
Two Intel Pentium Pro processors, 331.78 total bogomips, 32M RAM
System library 2.0.97

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    I agree with this.  But from a practical viewpoint, frequently running 
    regression tests on a variety of host/targets is important even if you
    have unit tests.

Of course!  I don't think anybody would disagree with that.

    I think it would be interesting to see how these standards could be
    applied to such a distributed, volunteer based development effort.

I do too, but I suspect such efforts would rate very poorly.

    There are certainly benefits to ISO 9000 and SEI levels.  Both require
    some administrative infrastructure and controls which would be
    challenging to have in a distributed environment.  Interesting.

I agree.

    > It is possible to derive *some* information from bugs, but what you
    > have to look at is not the number of bugs but the nature of each in
    > detail.  I'm not that familiar with the work that's been done in that
    > area.

    Yes.  If you get 12 reports of the same bug, only one good test case
    should enter the regression tests.

Right.

    On a related note, bugs should be tracked by subsystem or module so a
    piece of the implementation with high defect rates can be redesigned.
    I have seen a handful of articles which claim this type analysis and
    replacement of problem code can be highly beneficial.

Yes, this is the sort of thing I mean.  Also, when you see bugs that relate
to what the valid range of operands a function can have, it's important
to see whether the documentation is accurate since one of the most critical
ways in which you rate the robustness of a large program is how accurate
the documentation is and how well it provides a tight specification.

So a bug that's isolated to one routine is not one I'd count against
the reliability of a program nearly as much as one that's caused by a confusion
of what's expected between two parts of the program.

One of the major weaknesses of GCC has always been that it has very poor
documentation, especially of the interfaces between functions.  Most of
the discussions of what the valid ranges of arguments are live in people's
heads and not in the comments in the code.  I've been trying to improve
that as I change things and have been increasingly strict in recent years to
make sure that this is placed in all new code.

Re: GCC2 merging (was "native language support now available")

[Charles M. Hannum]

> You mean overall testing.  People in the software engineering community often
> say that such testing isn't very valuable.  The kind of testing that's the
> most important in producing high reliability software is *unit testing*,

While it's true that component testing is not (AFAIK) done for either
system, even if it were, you *still* have to test the system as a
whole.  Your specifications could be wrong.

And while it's true that it would be better if component testing was
done, that amounts to throwing up your hands and ignoring the testing
problem.  egcs at least has a formal test suite, and does identify and
fix bugs using it.  It's certainly far better than nothing.

Re: GCC2 merging (was "native language support now available")

[Richard Stallman]

    How do you propose to progress this - is there even a real issue
    beyond turf war?

I'm open to having the EGCS team become the GCC maintainers
and making EGCS the official version of GCC.

Re: GCC2 merging (was "native language support now available")

[Richard Stallman]

    No dishonest promise was  ever made to the GNU  project

Please note that I did not say it was dishonest.
That was apparently the assumption made by someone else;
I commented on his attitude, but I explicitly said
I was not sure his assumption was true.

I'm sorry if that was not clear.

Re: GCC2 merging (was "native language support now available")

[Joe Buck]

RMS writes:
> Do you really have so little respect for the GNU project that you
> smile at the idea of making a dishonest promise to it?

No dishonest promise was  ever made to the GNU  project (rather, since one
cannot make a promise to an abstraction,  no dishonest promise was made to
you).  You were told that there would be releases,  and you were told this
before the public was told about  egcs.  You were  also told that the egcs
team considered the project experimental and that this  is what the public
would be told.  However you were also told  that the bazaar model would be
used;  this   means that the   public would  be   *encouraged* to  bang on
experimental code, not discouraged as was done with gcc2.

The egcs team took a number of steps to avoid a permanent fork: it is
required that all contributed patches be assigned to the FSF; the GNU
coding standards were followed, etc -- the idea was to ensure that all
egcs code could be moved to an "official" gcc any time.  This is what
we meant by "no permanent fork" -- we were not going to create another
XEmacs.

Also, as was explained from the beginning, egcs was not simply
experimenting with patches to gcc.  It was, more than anything else, an
experiment with the gcc development model, heavily influenced by ESR's
famous paper as well as the success of the Linux kernel development.  Now,
we thought it would work but we did not know this.

The folks who started egcs formed a spectrum of opinion, and some of them
would have been fine with doing a fork.  This may be why you may feel that
the promises made were dishonest (also, since no one else but you and
Gumby were in on private conversations, we can't be sure that Gumby didn't
tell you anything inaccurate; if he did, I'm sure it was mistaken and not
intentional -- and I'm fairly sure that he told you that he was not the
boss of egcs).  But most of us, I think, wanted to reform gcc's
development, not split off from it.

When an experiment is conducted, the result is not always what
is expected.  Had egcs devolved into a mess, we could then have fished
out the "good stuff", cleaned it up, and sent it to gcc2 to integrate.
But egcs was wildly successful by any measure.

When there is an accepted treatment for a disease, and there is a new
treatment of unknown promise, it would be irresponsible for a physician
to recommend the new treatment, even if there were no regulatory
agencies.  So initially, there would be an approved treatment and an
experimental treatment.  But once the experiment proves its superiority,
it is no longer responsible to continue to recommend the traditional
treatment.  At that point, you will start to see pressure to remove the
"experimental" label.

When the same organization (in this  case, the FSF)  owns both the old and
new treatments, it should not be that difficult to manage a transition.

RE: GCC2 merging (was "native language support now available")

[James Mansion]

> From: Richard Stallman [ mailto:rms@gnu.org ]

> As a factual matter, this promise has not been kept.

> Do you really have so little respect for the GNU project that you
> smile at the idea of making a dishonest promise to it?
> 

Post 2.7.2 development has hardly merited respect.  Its been a
PR disaster and the rate of improvement seen in egcs (not least
the approach to testing and addition of thread, exception and
template functionality) shows what is possible.

Most users and (in particular I guess) ISVs would love there to
be one nice central development effort.  But we're not prepared
to see the stagnation that we've seen previously, and not
prepared to lose the real advances being (and been) made in egcs.

How do you propose to progress this - is there even a real issue
beyond turf war?

JAmes

Re: GCC2 merging (was "native language support now available")

[Joe Buck]

> Making sure that participants have fun is indeed an important part of
> a successful project, but is hardly the only one.  And often that part
> conflicts with more important parts.  Consider avionics software:
> every minor change can needs hundreds of pages of documentation and
> approvals of a dozen people.  It is not at all fun, but people who do
> it get paid a lot and the software is highly reliable.

Correct.  So if gcc2 were more reliable than egcs, that would be an
argument in its favor.  Is it?

The answer, unfortunately, is that it is not.  The reason is that egcs
has not only been more successful in recruiting developers, but also
in recruiting testers and in doing tests in a consistent manner.

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    Perhaps it would be beneficial if you were to take a step back from
    the whole situation and ask yourself WHY there are so few volunteers
    to the GCC2 project any more, and why EGCS has almost more than they
    would need or want.

That's very clear and I said so in a message a while ago: when people
are volunteers, as opposed to being paid, they do what's the most fun.
And it's much more fun to work on a project where changes are less
controlled than one where they are more controlled.  As you say.

    Maybe (just MAYBE) another reason is that the model used by the EGCS
    team works better. I cannot speak for others (as much as I'd like to
    speak for R.J.L) but from my own experiences, I have had a FAR more
    pleasant experience working on EGCS than I ever did working on GCC2. 

Making sure that participants have fun is indeed an important part of
a successful project, but is hardly the only one.  And often that part
conflicts with more important parts.  Consider avionics software:
every minor change can needs hundreds of pages of documentation and
approvals of a dozen people.  It is not at all fun, but people who do
it get paid a lot and the software is highly reliable.

A more general fact is that most people don't like writing documentation.
They'll have much more fun if they don't have to write it at all.  So
the project that's the most fun will usually be the one with the
least documentation.  You can't look at the "fun factor" and try to
use that alone to rate the success of a project.

Re: GCC2 merging (was "native language support now available")

[J. Kean Johnston]

> indicate when a particular piece of work was no longer experimental), then I
> strongly agree with you: that lack of volunteers was most unfortunate and has
> created the position we are now in.

Perhaps it would be beneficial if you were to take a step back from the
whole situation and ask yourself WHY there are so few volunteers to the
GCC2 project any more, and why EGCS has almost more than they would need
or want. What makes the two projects so different that the one attracts
hundreds of good technical messages a day, open, lively debate and a
program that is moving forward, while the other has traffic that seems to
be almost exclusively political. Maybe thats one reason.

Maybe (just MAYBE) another reason is that the model used by the EGCS team
works better. I cannot speak for others (as much as I'd like to speak for
R.J.L) but from my own experiences, I have had a FAR more pleasant experience
working on EGCS than I ever did working on GCC2. I am a programmer, not a
politician, and I prefer to code than bicker. It seems that it get CODE
accepted into EGCS I can 'talk tech" ... when I tried on many occasions to
get sane, sensible patches into GCC2, it was more like a begging process,
and I spent a good few days after every attempt to send a patch on the
defensive.

My $0,02 worth, the EGCS project is a big success, and the GCC2 project
is heading for failure. Instead of debating subtle little points, lets
quit the politics and contribute code. Lets make the compiler better. Which
one? EGCS. It has life.

BTW ... you can do a sed -e 's/GCC/Emacs/g' -e 's/EGCS/XEmacs/g' on the
above message and everything I said holds true. Thats two projects I have
personallyl be involved with where the more open, co-operative model works
so much better than the original GNU model. Perhaps theres a lesson in
there somehwere.

-- 
J. Kean Johnston  | "Every day, computers are making people easier
Engineer, SPG     |  to use" -- Source unknown.
Santa Cruz, CA    +----------------------------------------------------------
Tel: 831-427-7569    Fax: 831-429-1887    E-mail: jkj@sco.com

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    I and the EGCS people with whom I regularly interract made the promise
    in good faith and have tried to work in good faith.  I may not have
    liked it, but I agreed to it and have been working to uphold it.  I
    was leery that GCC2 would work to incorporate the experimental work in
    a timely fashion, and my concerns seem to have been justified.  

"GCC2" is not a corporation or a funded entity, or even a small number of
specific people.  It's mostly a set of volunteers who submit patches and test
the result.  Both RMS and I tried very hard to convince the people who
originally wrote the patches to submit them to the GCC2 project when they
were no longer exprimental and also tried to find volunteers to assist in
this process.  Nobody came forward except Andreas Schwab, who submitted the
regmove.c part of EGCS, which I subsequently put into GCC2.

So I'm not sure who you are being critical of here.  If you are being
critical of the fact that nobody volunteered to do the work (or even to
indicate when a particular piece of work was no longer experimental), then I
strongly agree with you: that lack of volunteers was most unfortunate and has
created the position we are now in.

Re: GCC2 merging (was "native language support now available")

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> "GCC2" is not a corporation or a funded entity, or even a small number of
Richard> specific people.  It's mostly a set of volunteers who submit patches and test
Richard> the result.  Both RMS and I tried very hard to convince the people who
Richard> originally wrote the patches to submit them to the GCC2 project when they
Richard> were no longer exprimental and also tried to find volunteers to assist in
Richard> this process.  Nobody came forward except Andreas Schwab, who submitted the
Richard> regmove.c part of EGCS, which I subsequently put into GCC2.

Richard> So I'm not sure who you are being critical of here.  If you are being
Richard> critical of the fact that nobody volunteered to do the work (or even to
Richard> indicate when a particular piece of work was no longer experimental), then I
Richard> strongly agree with you: that lack of volunteers was most unfortunate and has
Richard> created the position we are now in.

	I have volunteered to integrate rs6000 port, collect2, and loop.c
changes into GCC2, but you have made it very difficult for me to the point
where I do not have time to perform the additional work above and beyond
addressing technical matters.

David

Re: GCC2 merging (was "native language support now available")

[Toon Moene]

John Vickers wrote:

>      Perhaps it's time to drop the "experimental", which
>      was only ever really a polite fiction.

and Richard Stallman replied:

>  When Gumby told me about his intention to start another
>  branch in GCC development.  I objected that it was likely
>  to result in a permanent fork.  He made a promise to the
>  GNU project that he would prevent this, by designating
>  the new branch for experimental use only.  The word
>  "experimental" was put in the name in order to inform
>  the public of this.

And if you search http://www.dejanews.com for the string "egcs"  
you'd know quite well that the "general public" thinks of egcs that  
way.

>  As a factual matter, this promise has not been kept.

In what sense ?  The development process initiated by egcs is  
"experimental" in the sense that we do not know whether it is the  
best way to develop a Free Compiling System.  We _do_ know, however,  
that this method attracted useful contributions from people that we  
(the gang of 25 undersigning the original announcement) didn't know  
of.

>  You're saying that this promise was a deliberate lie from
>  the beginning.  I don't know if you're right, but I see
>  you enjoy thinking so.

It was unclear from the beginning how "successful" egcs would be -  
one of the issues discussed before `going public' was the danger of  
"melt-down", i.e. maintainers being overwhelmed with -  
well-intended, but useless - patches.  The amazing thing is that  
this happened, but could be controlled.  In this sense, the  
experiment "succeeded".  In this sense, we are enjoying the "egcs"  
initiative.

>  Do you really have so little respect for the GNU project
>  that you smile at the idea of making a dishonest promise
>  to it?

If *I* wouldn't have respect for the GNU project I wouldn't fund it.

Regards,
Toon.

Re: GCC2 merging (was "native language support now available")

[Jeffrey A Law]

  In message < 9810111915.AA07497@vlsi1.ultra.nyu.edu >you write:
  > So I'm not sure who you are being critical of here.  If you are being
  > critical of the fact that nobody volunteered to do the work (or even to
  > indicate when a particular piece of work was no longer experimental), then I
  > strongly agree with you: that lack of volunteers was most unfortunate and h
  > as created the position we are now in.
Speaking strictly for myself, I no longer volunteer significant amounts of my
time to gcc2 because I've found working within the gcc2 development model too
mainful and frustrating.

If it were not for egcs I would have completely quit any kind of gcc development
by now.


jeff

Re: GCC2 merging (was "native language support now available")

[Richard Kenner]

    I have volunteered to integrate rs6000 port, collect2, and loop.c
    changes into GCC2, but you have made it very difficult for me to the
    point where I do not have time to perform the additional work above
    and beyond addressing technical matters.

I agree that the reformatting made it a bit more work to integrate the
rs6000 port changes and that was unfortunate (though I made those
changes at a time I had no way of knowing you were trying to do this).

This is the first I hear, however, of your offer to integrate the
collect2.c and loop.c changes into GCC2.  Thank you very much for
offering to do that.  Can you send those changes to me when you have
them?  I don't believe either of those files has changed much
recently.

Re: GCC2 merging (was "native language support now available")

[David Edelsohn]

>>>>> Richard Stallman writes:

> Perhaps it's time to drop the "experimental", which was only
> ever really a polite fiction.

Richard> When Gumby told me about his intention to start another branch in GCC
Richard> development.  I objected that it was likely to result in a permanent
Richard> fork.  He made a promise to the GNU project that he would prevent
Richard> this, by designating the new branch for experimental use only.  The
Richard> word "experimental" was put in the name in order to inform the public
Richard> of this.

Richard> As a factual matter, this promise has not been kept.

Richard> You're saying that this promise was a deliberate lie from the
Richard> beginning.  I don't know if you're right, but I see you enjoy thinking
Richard> so.

Richard> Do you really have so little respect for the GNU project that you
Richard> smile at the idea of making a dishonest promise to it?

	There is a difference between a polite fiction because people
intentionally were misleading and made a commitment in bad faith versus a
fiction because it has been impossible to implement the agreement.

	I and the EGCS people with whom I regularly interract made the
promise in good faith and have tried to work in good faith.  I may not
have liked it, but I agreed to it and have been working to uphold it.  I
was leery that GCC2 would work to incorporate the experimental work in a
timely fashion, and my concerns seem to have been justified.  That is my
perspective and you obviously view the situation differently.

David

Re: GCC2 merging (was "native language support now available")

[Richard Stallman]

    > We also would like these companies and
    > others to get the benefits of work in EGCS that's ready for production use.

    Perhaps it's time to drop the "experimental", which was only
    ever really a polite fiction.

When Gumby told me about his intention to start another branch in GCC
development.  I objected that it was likely to result in a permanent
fork.  He made a promise to the GNU project that he would prevent
this, by designating the new branch for experimental use only.  The
word "experimental" was put in the name in order to inform the public
of this.

As a factual matter, this promise has not been kept.

You're saying that this promise was a deliberate lie from the
beginning.  I don't know if you're right, but I see you enjoy thinking
so.

Do you really have so little respect for the GNU project that you
smile at the idea of making a dishonest promise to it?

Re: GCC2 merging (was "native language support now available")

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > These were introduced as a large patch, submitted from someone, but I
 > believe new improvements that might cause long-term instability would
 > be introduced in egcs as separate branches or as features that can be
 > enabled by command-line arguments or configure switches, disabled by
 > default until the feature stabilizes.

 > This is exactly what is happening within the C++ front-end: the new
 > name mangling mechanism (-fsquangle), the empty base class
 > optimization (-fnew-abi) and the std namespace compliance
 > (-fhonor-std) are all in this stage of development, but they can all
 > be used in full releases, as long as the user (hacker) knows that they
 > are not as fully tested as the stable part of the compiler.

FWIW, these are currently options that are off by default not because they
are immature, but because they would break binary compatibility; we're
saving them up to switch over all at once.

Jason

Re: GCC2 merging (was "native language support now available")

[Mike Stump]

> Date: Wed, 30 Sep 1998 16:16:11 +0100
> From: John Vickers <jvickers@acorn.com>
> To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
> CC: davem@dm.cobaltmicro.com, gcc2@cygnus.com, egcs@cygnus.com

> Richard Kenner wrote:
> > 
> >     Why not make EGCS the definitive source base and be done with it.
> > 
> > Because there remains a need for both types of source bases: one that
> > encourages rapid development and testing of experimental code (for the
> > development community) and one that encourages stability (for the
> > commercial community).

Well, you know what company I work for, and our market share speaks
for itself.  I do consider us commercial, further I think that egcs
better fills our needs than gcc2, and that is the only source base
that I would consider using at this point in time, other than legacy
source bases.  As a company we also use proprietary compilers and
contracted compilers that may be different from egcs, but the
migration path and first choice solution (if it work) is egcs.

> I thought egcs releases these days got a lot more testing and more
> systematic testing than gcc2 releases.  I haven't seen a whole lot
> of traffic on gcc2 regarding testsuite results or testing by
> building known packages (or regarding anything else for that
> matter).

Anybody that is interested can review the past year of egcs and gcc2
and see what exactly is tested and what exactly isn't.  I do feel egcs
has gcc2 beat on actual real live testing.

> > We also would like these companies and others to get the benefits
> > of work in EGCS that's ready for production use.

If there is a part of egcs 1.1 that isn't ready for production use,
could you improve it, prepare it for production use, and call that
gcc-2.9 or 2.10?  At some point, the sources need to merge, or one of
the sources needs to die.  Could we have a roadmap from you stating
gcc2's future?  The egcs source base has a clear future to me.

> Perhaps it's time to drop the "experimental", which was only
> ever really a polite fiction.

I agree.  It is a polite fiction.  I find nothing experimental about it.

> > Moreover, so long as that project remains in Cygnus, there is
> > another potential conflict: Cygnus is moving to become a company
> > who's major product is a proprietary IDE.

And they recently introduced a royalty free source OS which vies for
becoming a major product.

> > That puts it in competition with these other companies, most
> > notably Wind River,

Yes.  And my goal is to work with the egcs community at large and
incorporate improvements and contribute testing results.  gcc2 is a
stable unchanging compiler, all the features and all the bugs remain
stable.  People that sit back in this world and relax and don't do
anything, quickly find themselves without an audience.  This is also
in part why I pick egcs over gcc2.  I knew what would happen within a
year, and it did.

> > It's uncomfortable for most companies to put control of an
> > important asset in the hands of somebody who has become a
> > competitor.

For people that understand the concept (maybe most don't?), it isn't
as scary as you might think.  Either egcs is technically superior,
well tested, well respected, trusted, has an active following that is
responsive to bug reports and incorporates work that is critical to
your companies success in the marketplace, or it isn't.  I am paid in
part to make that determination based upon all I know and the people
and organizations involved.  The day egcs isn't the technical
solution, is the day I switch.

> > One company I was talking to (not one that I listed) is already
> > concerned about this and the problem will get worse, not better,
> > over time.

?  I don't follow this part.  Could you please state the fears that
the person has.  If Cygnus ever does something that you feel is wrong,
I hope you will complain loudly.  So far, there have been a few things
that I didn't like, and I complained.  I hope to see them resolved.
The most notable is the licensing and legal status of the new
libstdc++ rewrite.  My perference is the status quo, FSF owned, libgcc
style copyright.  It works and has been working for years.  Why change
it?  I can't fathom a heathly reason why.  The worst case isn't
exactly what I want to see happen, but I have a strategy for solving
that problem, should it ever need a solution.  Some of my fears were
eased when the clarified they wanted it to be freely usable, but not
all.

If Kenner would accept the donation of egcs 1.1, and Cygnus were to
assign copyright to the FSF, then I would ask Kenner to put the libgcc
style copyright back on the libstdc++ code, and the entire problem
solved.  Kenner, if you fail to do this, then I have a whole lot less
leverage on getting this accomplished.  And I may have to pay for your
decision.

Re: GCC2 merging (was "native language support now available")

[Alexandre Oliva]

John Vickers <jvickers@acorn.com> writes:

> As Alexandre said, egcs hasn't made radical optimisation changes.

Actually, there *have* been radical optimizations: the new alias
analysis code, the haifa scheduler and the global common
sub-expression elimination have all been introduced in egcs, but not
in gcc.  However, none of them has delayed releases, AFAIK.  Which
does not mean they are simple; it's just that they have been
introduced almost atomically.

These were introduced as a large patch, submitted from someone, but I
believe new improvements that might cause long-term instability would
be introduced in egcs as separate branches or as features that can be
enabled by command-line arguments or configure switches, disabled by
default until the feature stabilizes.

This is exactly what is happening within the C++ front-end: the new
name mangling mechanism (-fsquangle), the empty base class
optimization (-fnew-abi) and the std namespace compliance
(-fhonor-std) are all in this stage of development, but they can all
be used in full releases, as long as the user (hacker) knows that they
are not as fully tested as the stable part of the compiler.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: GCC2 merging (was "native language support now available")

[Alexandre Oliva]

John Vickers <jvickers@acorn.com> writes:

> Alexandre Oliva wrote:

>> I haven't been testing gcc2 any more, because it doesn't include a
>> testsuite, which makes testing it much harder than egcs.  Furthermore,
>> I don't believe gcc2 is going to evolve any more.  I see no reason to
>> work on it, since egcs is doing that well.

> It's funny how more-or-less the same people seem to get a whole lot more
> done since egcs started.

It's not that funny.  As I see it, maintaining gcc was too much work
for a single person, even for someone as skilled as Richard Kenner.
His overload, as well as the fact that he sometimes sounded harsh (but
it's just the way he writes), has caused some people to give up
contributing to gcc.

Opening the development process, so that different tasks could be
taken care of by different people, has made it possible for egcs to
evolve as fast as it did, without overloading anyone (or rather
overloading a lot of people :-)

The Cathedral spirit has contributed very much to make people think of
Kenner as an adversary, rather than as one important member of the
team.  With the Bazaar model, the cooperation attitude is made much
clearer, since everybody can see all patches, comment on them, discuss 
them, up to the point that we agree on a good solution.

This is not what used to happen in the old model: Kenner would usually
discuss with the submitter of a patch in private, and this would make
him sound more like an adversary.

> What does specifically does gcc have these days, apart from the brand
> name ?

AFAIK, internationalization support is the only major improvement of
gcc that has not been imported into egcs yet.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: GCC2 merging (was "native language support now available")

[John Vickers]

Richard Kenner wrote:
> 
>     I guess if there were a load of people saying "I Don't Want any more
>     C++ changes !" - or somesuch - egcs could bring out 1.0.4 & 1.0.5,
>     while releasing 1.2.  But I'm not aware that there's much call for
>     that kind of stability (not that I'm likely to be particularly well
>     informed in this matter).  If the user really want's stability, they
>     can carry on using the same compiler version.
> 
> Front end changes aren't the issue, it's optimizer changes.
> 
> The Linux community, though becoming increasingly commercial, has
> traditionally been one of wanting "the latest and greatest of anything"
> (and, by the way, that attitude is a major restraint on the growth rate).

As it happens, I'm not sure that's a good example for you,
since the Linux people have had difficulties
with their elaborate asm's under egcs.

> 
> The users I'm talking about are in the traditional area for GCC of embedded
> systems and the vendors that target them.  They certainly want to be able to
> give their users the benefit of new optimization technology, but have a very
> high cost of changing compilers and so only want to see a major feature when
> it's completed, not when it's in progress.

Are we talking about stability or reliability now ?

Well fine, what's the problem - if they're worried about new features in
X.Y.0,
they should do a load of testing themselves and/or wait for X.Y.1.

As was said before, egcs testing is a whole lot more thorough
now than gcc testing is or ever was.

As Alexandre said, egcs hasn't made radical optimisation changes.
If it did, who cares what happens under the bonnet,
so long as the damm thing works.

I *am* an embedded developer, and have been for several years now.
I don't (personally) see major costs in switching between gcc & egcs,
compared to the costs of switching between either of those and a
compiler
from a completely different stable.  Indeed, I worked on development
projects where the compiler used changed three times in six months
within the
egcs/gcc family (only counting major versions) without any
disruption noticeable to me at all.
There are certainly some potentially big issues with the evolving C++
implementations, but in practice I haven't seen them.  My experience
isn't with a *vendor* of embedded development systems, which is more
what
you're talking about, but it does include development from the bare
board
up (from the schematic up, sometimes), with an number of gcc family
compilers.

John.

Re: GCC2 merging (was "native language support now available")

[Gary V. Vaughan]

Alexandre Oliva wrote:
> 
> John Vickers <jvickers@acorn.com> writes:
> 
> > Perhaps it's time to drop the "experimental", which was only
> > ever really a polite fiction.
> 
> How about replacing `experimental' with `extended'?

It is referred to as 'enhanced gnu compiler system' on the `net
already...  is this not yet the official title?

Cheers,
	Gary V. Vaughan

Re: GCC2 merging (was "native language support now available")

[John Vickers]

Alexandre Oliva wrote:
> 
> I haven't been testing gcc2 any more, because it doesn't include a
> testsuite, which makes testing it much harder than egcs.  Furthermore,
> I don't believe gcc2 is going to evolve any more.  I see no reason to
> work on it, since egcs is doing that well.

It's funny how more-or-less the same people seem to get a whole lot more
done since egcs started.

> > Perhaps it's time to drop the "experimental", which was only
> > ever really a polite fiction.
> 
> How about replacing `experimental' with `extended'?

I think the web pages say something about the 'e' not standing for
anything
in particular at all, or perhaps standing for whatever happens to be
expedient at the time.

Why bother with merging anyway ?  

What does specifically does gcc have these days, apart from the brand
name ?

These are not just rhetorical questions, I would be interested to know
what the answers are.

John.

Re: GCC2 merging (was "native language support now available")

[Alexandre Oliva]

John Vickers <jvickers@acorn.com> writes:

> I haven't seen a whole lot of traffic on gcc2 regarding testsuite
> results or testing by building known packages (or regarding anything
> else for that matter).

> Maybe you do a load of testing, & don't talk to anyone about it ?

I haven't been testing gcc2 any more, because it doesn't include a
testsuite, which makes testing it much harder than egcs.  Furthermore, 
I don't believe gcc2 is going to evolve any more.  I see no reason to
work on it, since egcs is doing that well.

> Perhaps it's time to drop the "experimental", which was only
> ever really a polite fiction.

How about replacing `experimental' with `extended'?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: GCC2 merging (was "native language support now available")

[John Vickers]

Richard Kenner wrote:
> 
>     Why not make EGCS the definitive source base and be done with it.
> 
> Because there remains a need for both types of source bases: one that
> encourages rapid development and testing of experimental code (for the
> development community) and one that encourages stability (for the
> commercial community).

I thought egcs releases these days got a lot more testing
and more systematic testing than gcc2 releases.
I haven't seen a whole lot of traffic on gcc2 regarding testsuite
results
or testing by building known packages (or regarding anything else
for that matter).

Maybe you do a load of testing, & don't talk to anyone about it ?

If you don't, then presumably egcs would be likely to be
the more stable compiler anyway.

> We also would like these companies and
> others to get the benefits of work in EGCS that's ready for production use.

Perhaps it's time to drop the "experimental", which was only
ever really a polite fiction.


> Moreover, so long as that project
> remains in Cygnus, there is another potential conflict: Cygnus is moving to
> become a company who's major product is a proprietary IDE.  That puts it in
> competition with these other companies, most notably Wind River, where
> previously they were working symbiotically.  It's uncomfortable for most
> companies to put control of an important asset in the hands of somebody who
> has become a competitor.  One company I was talking to (not one that I
> listed) is already concerned about this and the problem will get worse, not
> better, over time.