Re: [Ada] Bootstrapping mainline GNAT fails

[dewar at gnat dot com (Robert Dewar)]

> Now, I get the impression that Ada has come into GCC with a totally
> different mindset.  It appears that, instead of even making attempts
> to widen the set of bootstrap compilers that could be used, the
> maintainers of the GNU Ada Compiler seem to imply that the only way
> they care about is a particular version of GNAT released by ACT.

No, that's not stating things quite right. We certainly do make attempts
to widen the set of bootstrap compilers that can be used. For example,
there is a quite concious attempt not to use 3.14 features yet, and we
verify that this is the case.

However, dealing with arbitrary compilers that are broken (as in the
case which caused this long thread) is another matter entirely. For example,
A requirement not to use exceptions at any point in the compiler would be
a fairly severe restriction. It is true that we are not far from meeting
this, but I can easily see cases in the future where it would be a real
problem. So we seem to have a rule right now that says:

  "you must use a compiler that generates correct code for built
  in longjmp and built in setjmp to bootstrap GNAT"

That's not such an unreasonable situation. Now it is desirable to be able
to bootstrap without depending on exceptions sure, and the particular
exception that was raised here might as well be removed.

But the fact remains that if you want to save yourself trouble, you should
use the C compiler that comes with the GNAT compiler.

The situation is very different between GNU C and Ada here. In order to
bootstrap GNAT, you absolutely MUST have a binary copy of a previous GNAT.
There is no way around that *at all*. Given that every such binary port of
GNAT also comes with a C compiler known to do the bootstrap successfullyl
I do not see what the big fuss is about, the recommendation is simply to
use that C compiler for the bootstrap. It's always available if you have
GNAT around, and it is provided *solely* for the purpose of bootstrapping
GNAT.

> I'd much rather treat changes that cause releases of GNAT that used to
> be usable for bootstrapping to stop working as regressions that should
> be addressed in a timely manner, instead of promoting support for the
> use of a single bootstrap compiler or actively breaking builds that
> fail to use such compiler without a very good reason to do so.  I
> dn't mean to imply that we have the latter now, but I fear the
> current trend may get us there, and I don't want us to get there.

That would prevent using new features in GNAT completely, and would prevent
any changes to the runtime units used in GNAT. It's too restrictive for
too little gain. If we had followed this rule for ever, GNAT would still
be written in Ada 83 :-)

Furthermore, the particular issue that raised this thread, despite 
earlier impressions to the contrary, had nothing whatsoever to do
with earlier releases of GNAT not being usable.

Sorry for the long thread here on this subject, but this is definitely
an area that needs to be sorted out, and the series of reports here has
been a bit confusing