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

[Zack Weinberg <zack at codesourcery dot com>]

On Tue, Mar 19, 2002 at 10:46:16AM -0500, Robert Dewar wrote:
>  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. 
...
> 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.

Um, no, actually, the C compiler also uses a fairly limited subset of
the language.  It's not as obvious, since C is a much smaller language,
but I've had experimental patches bootstrap successfully yet cause
thousands of regressions.  This is what the test suite is there for...

> 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.

I think there might be value in splitting hairs a bit finer with
the definition of "works".

(a) Whether a compiler generates correct object code for correct
input, modulo unsupported language features and bugs yet to be found.
I think this is what Alexandre means by "works".

(b) Whether a language implementation supports enough of the language
to be generally useful.  This is what you appear to mean by a
completed GNAT port.

In the presence of buggy bootstrap compilers, (a) is more likely to be
satisfied the fewer language features the compiler itself uses --
since it is less likely to trigger those bugs.  On the other hand, the
fewer language features the compiler uses, the less satisfying (a)
tells you about (b).

It seems to me that trying to deduce (b) from (a) has little value; we
have test suites to verify (b) on its own.  It also seems to me that
increasing the odds of (a) being true by using a limited language
subset is simply good defensive programming.

> 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.

The original reason I got into this thread was to raise a concern
about this policy -- not actually to get the current bootstrap
failures fixed.  Let me try to re-state my concern in more reasonable
language.

Even if a release is available, that does not mean it is in widespread
use.  System integrators tend to lag one or two releases behind, so
they can do testing of their own.  Also, right now we have a major ABI
and API change going from 2.x to 3.x.  It primarily affects C++, but
there's a lot of C++ out there, so most distributions I know are
holding off bumping the default system compiler to 3.x until they have
a chance to validate their code and make sure they have a tested
upgrade path.

Therefore, I'm nervous about dropping support for GNAT 3.1[34] the
moment GCC 3.1 ships.  I would like to see that change postponed at
least until several major free operating systems have made the
transition to 3.x as primary system compiler.  Otherwise, we may make
it *harder* for those vendors to make that transition.  If they don't
get around to it until 3.2 is out, for instance, they will need to do
the extra work of packaging 3.1 first just so they can build all of 3.2.

zw