Why not gnat Ada in gcc?

[Robert Dewar]

<<I disagree again.  If you look at the major restructuring changes that have
happened with GCC over the 3 years since its development was opened up, you'll
find that the community was able to deal with rapid development and daily
instability.  Examples would be moving to garbage collection technology in
the compiler, a completely revamped reload pass, massive C++ improvements,
a much more aggressive internal consistency checking system in the compiler,
implementing a real CFG and using it in the optimizers, etc etc.
>>

Yes, but of course you cannot deal with daily instability for actual
commercial development for large scale customers who depend on absolute
stability.

Our internal development tree always maintains close to absolute stability
(we do not permit even the most minor change to be made without FIRST
running our entire regression suite, and no change can be made if it
causes any regressions at all). Then we run all versions on all targets
every night to absolutely ensure that no regressions have occurred.
This testing depends of course on large volumes of proprietary code
as well as proprietary test suites. We do also use the open ACATS
suite, but that's only a small part of the testing.

I don't think that kind of very controlled development is appropriate
to the open tree, as you say, in this environment people can indeed deal
with daily instability.

It is interesting to note the fuss about Redhat distributing a non-official
release of GCC, where poeple worried about instability. In our internal
environment we distribute daily builds to customers to fix bugs as needed,
because we know that they are completely solid. I don't think anyone
would suggest that daily builds from the open gcc tree could be immediately
be integrated into production environments.

The task is to try to coordinate the stable customer-oriented, extensively
tested internal development with more open development. We will have to
find our way to the best way of doing this. I must say that if the GNAT
front end showed the same kinds of daily instability we see in the open
GCC backend, that will make things much harder, but I think that is
relatively unlikely, simply because I don't see that many people making
changes to the hard parts of the front end. 

Incidentally, one thing that I do NOT think is addressed well enough in
the GCC development process is performance issues. As far as I can tell
there is very little systematic performance testing, and we are somewhat
dismayed to find a significant decrease in not only compile time 
performance, but also runtime performance of GCC 2.9x compared to
GCC 2.8.1. We hope this can be resolved, but right now, this will
make it more difficult to complete the switchover for GNAT, since
certainly our serious customers cannot tolerate even a 5-10% performance
degradation in some cases ... definitely something to worry about.

I am surprised this is not more of a problem for others...