Re: patch for -Wno-long-long and early GNAT compilers

[dewar at gnat dot com (Robert Dewar)]

<<It's this attitude that bothers me, despite my seeing a rationale for
it.  Look, I don't care who's the provider of the single gnat
bootstrap compiler, I dislike the fact that it *is* a single gnat
bootstrap compiler, as opposed to the more traditional GCC approach
of the problem, that I can summarize as `look, we can't guarantee it
will build and work with any C compiler every written under the sun,
but if it manages to get GCC to the end of a bootstrap, odds are that
the resulting compiler works'.
>>

That's not going to be true with GNAT. The situation is quite different
from C. The GNAT compiler uses only a small subset of the capabilities
of Ada (and indeed to some extent this discussion is about restricting
the growth of that subset).

This means that if GNAT bootstraps, you can still be a long way from having
a reasonably working compiler. 

This is not a matter of attitude, it is a matter of fact ..

For example, the compiler uses no tasking. We routinely bootstrap GNAT before
we even have a tasking run time.

As for exceptions, with regard to the criterion of a bootstrappable compiler
working, we have actualy gone backwards, since we have now, at least for the
moment ensured that the compiler can bootstrap with exceptions completely
broken. An Ada compiler with exceptions broken can hardly be said to "work".

The C compiler on the other hand uses most of C, and so in practice the
completion of a bootstrap is a reasonable indication of working.

We now have three quite separate issues

1. The issue of whether a compiler that bootstraps probably works (that's a new
issue raised with this mail from Alexandre, and addressed above. We actually
regard getting GNAT to bootstrap as a very small fraction of the work of
completing a GNAT port. For example, we have the ia64 GNAT bootstrapping, but
it is nowhere near working yet.

2. The issue of maintaining language compatibility with old versions of 
GNAT. I don't think one can take an absolute position on this. Certainly
GNAT is nowhere near the Mercury extreme of breaking the bootstrap frequently.

Our normal policy has been that we must always be able to build with the
previously available release. Since releases come every year or so, that means
that we usually wait about two years before using new features. This does mean
that a GNAT that is over two years old may not work. Right now, we are for
the moment maintaining compatibility one extra version back (to 3.13) so you
have to go even further back (to 3.12) to find a compiler that does not
support the language features fully).

3. The issue of building with broken compilers that generate wrong code. That
has been exhaustively and exhaustingly discussed :-)