Re: 3.2 PATCH: Fully support parallel gnat1/gnatbind builds

[Zack Weinberg <zack at codesourcery dot com>]

Responding to a whole bunch of messages at once...

Richard Kenner wrote:
>     I believe that __builtin_setjmp is the only place where version skew
>     between bootstrap compilers is a problem.  More accurately, I cannot
>     think of any other issue that would not represent a major
>     incompatibility in the C ABI, and would therefore have been noticed in
>     normal usage.
> 
> Remember that the GNAT C and Ada code freely call each other and make
> assumptions about how that will work that aren't part of the C ABI.

I would like to see actual examples of this causing problems, before
worrying about it.

> But if *all* the GNAT C code is compiled with the same compiler as the Ada
> code, then the only issue is the calls from the GNAT front end to the middle
> of GCC and there I agree with you.

It is not practical to compile ada/*.c with a different compiler from
the backend, because they may have different characteristics from
configure's point of view, which means auto-host.h will be wrong for
one of them.

Compiling the whole tree with the Ada-capable compiler would work if
we also insist that that compiler be >=3.1.  I would actually be okay
with this - see below.

Rainer Orth wrote:
> Right, that's almost certainly the right aproach: at the moment,
> bootstrapping with CC=cc (or some such) breaks if you happen to have an
> Ada-capable compiler in your path.  In this scenario, ada gets built, but
> in stage1, cc is used for all C sources.  But a non-gcc C compiler cannot
> in general compile the Ada C sources (which are written in the GNU C
> dialect).

Yes, this is a good point which was not raised in previous discussions.

Robert Dewar wrote:
> No, we haven't! We have talked about 3.1, but not about 3.2. I think it
> is appropriate to do some long overdue cleanups from bootstrap path kludges
> and it seems reasonable to me to require 3.1 for people who want to build
> 3.2 Ada. So I think this needs rediscussion.

I'm not opposed to requiring 3.1 Ada to compile 3.2 Ada.  It would be
nice if we could preserve bootstrap compatibility farther back, but if
there are major gains to maintainability from raising the bar, fine.

However, I do think that "$srcdir/configure; make bootstrap; sudo make
install" in a tree including Ada should Just Work on as many operating
systems as practical, without requiring the user to set CC=whatever.
That means configure needs to go find the right compiler.

For 3.2, raising the bar to 3.1 would actually eliminate the major
reason why I wanted CC != ADAC to work in 3.1, which is that the 2.8.1
era C compiler was not nearly as well tested as the 2.95 compiler
was.  Therefore we wanted to avoid using it as much as possible, to
reduce the risk of tripping a bug.

This is no longer a problem with the unified 3.1 release.

[People building from scratch starting with a C compiler other than
GCC are up a creek, but I believe that has always been the case for
the Ada front end.]

> That's odd, we did do a patch to eliminate this problem, what are you
> talking about?

There were two separate patches floating around.  One of them fixed
the bug with constant folding not handling string literals, which
caused an exception to be thrown in the first place; that one got
applied.

The other patch made exception handling work, by compiling
__gnat_raise_exception with $(ADAC).  That one got rejected.

zw