This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ada policy
Zack Weinberg wrote:
Having thought about this a bit more, I can only defend a slightly
weaker assertion based on messages I can actually find in the mailing
list archives. See my response to Kenner. Can you agree that a
reasonable person could have reached *that* conclusion?
Well quite a bit weaker actually :-) Saying that we were deliberately
breaking things seemed to be going a bit far!
The issue is a simple one. It is the extent of the guarantee that
it will be possible to bootstrap from previous versions. If you
imagine for a moment that the g++ front end were written entirely
in C++, I think you can see that it would not be quite so easy to
guarantee that it could be bootstrapped with any previous version
of g++. Of course everyone agrees that it is desirable to maintain
the broadest possible set of bootstrap paths (that's why the
accusation that we were deliberately breaking things rankled a
bit :-)
The question is whether you can guarantee that it will be possible
to bootstrap with all previous versions. Well of course you cannot
make that broad of a guarantee. So what you want to do is to balance
the conflicting goals here:
1. Provide a front end that is as efficient as possible, written
as clearly as possible.
2. Maintain general bootstrap paths
I think in practice we have made the right decisions here. The
only reported difficulty was when you (Zack) tried to use some
inconsistent versions of C and GNAT, and exceptions could not
be properly supported in that mixed environment.
The interesting thing here is that we have virtually no reports
of people having difficulty in practice bootstrapping Ada on all
sorts of targets where the difficulty arises from this consideration.
Seems a bit of a tempest in a teapot to me.
That is a good sign...
It is *certainly* not the case that any old arbitrary GNAT can be
used (there are dozens of versions stretching back over 13 years
after all!)
I continue to be disappointed that an arbitrary standard-conforming
Ada compiler cannot be used.
That would be a very fierce restriction, resulting in considerable
inefficiencies, since it would mean that we could not take advantage
of any of the standard GNAT pragmas and attributes, which are used
extensively (many of these attributes and pragmas were in fact put
there for use by the compiler in the first place, e.g. pragma
No_Return, so that we can turn on full warnings).
The probability of someone wanting to bootstrap GNAT starting with
an expensive proprietary compiler seems vanishingly small, given
that GNAT is so widely available, and that it is fairly easy to
build cross compilers to go to new architectures. I don't think
there are cases anyway (unlike the situation with GCC) where you
have an environment with an Ada compiler which is not GNAT, and
GNAT is not available.
Yes, in the abstract, this goal sounds desirable, but the gains
would be minuscule and the cost high. If you don't agree, spend
a bit of time (well it might take *quite* a bit of time) looking
through the sources to see how we use GNAT attributes. Look for
example at the use of 'Unrestricted_Access. Yes, you can remove
these uses, but in almost all cases you will do real damage to
the readability of the code. The technical problem here is that
Ada severely restricts the passing of subprograms as parameters.
Why? Becuase some other now defunct Ada compiler could not easily
support reasonable semantics, and the vendor screamed murder at
the standards committee. So everyone using standard Ada is stuck
with annoying work arounds.
Until such time as the distinction between the runtime and the
compiler proper is reflected in the organization of the source tree, I
cannot be bothered to figure out which is which.
That's fine, but be careful about basing deductions from this
position of lack of understanding of the distinction. In practice
there is no issue of making mistakes here, since if for example,
you incorrectly use pragma Unreferenced in the compiler proper,
the build will fail if you follow our style of using an early
version of the compiler for the bootstrap.
This must sound
dreadfully lazy to you, but consider that from my point of view,
checking in a grab bag of patches once a week with no public review is
far lazier. (You continue not to address this concern.)
It's not a matter of being lazy, it is simply a matter of resources.
If we had millions of dollars in the bank, and could afford to have
one or two full time people dedicated to the submission of patches
in a more separated way. I am dubious about review, almost all these
patches require a pretty detailed knowledge of GNAT to understand.
But review is always welcome (we certainly would welcome more
input anywhere on GNAT, and yes, if we spent more effort on how the
patches were submitted, it might help, but I doubt it). The situation
with back end general gcc patches is of course different, and as you
know these often get substantially discussed.
So we (AdaCore) have three choices at the moment
1. Don't submit Ada patches at all
2. Submit them as we are doing now, keeping the tree up to date
3. Submit them broken down, fully documented, with tests, for review
Yes, 3 would be nice, but there just aren't the resources to do it.
As it is doing 2 represents a significant investment for us. We
certainly recognize that we get a lot back for that investment,
but it already strains what we can achieve, given that attention
to supported customers is always our number one priority (without
the supported customers, there would be no patches from us :-)
So, not ideal, but 2 seems better than 1 to us, and arguing
strongly for 3 is not going to make much difference unless
someone is willing to fund this activity (in the old days
perhaps the AJPO could have been approached, but I don't
see any source for such funding today).
Robert