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

[Robert Dewar]

<<I was frustrated because I and others were getting bootstrap failures,
and the position the GNAT maintainers were taking was that it didn't
matter because the configurations we were using weren't supported.
Since the previous official word had been that they *were* supported
although possibly not constantly tested, I felt bait-and-switch-ed.
>>

Perhaps I just don't understand. Reading your latest messages, it seems
that the entire problem was that you were using a broken C compiler that
generated wrong code for longjmp/setjmp. It's not the C compiler we recommend
for compiling GNAT, and in fact, given that it is this broken, it seems a good
idea to actively recommend NOT using this C compiler.

You just seem to be making trouble for yourself by using other than the
C compiler that is supplied for the purpose of bootstrapping GNAT. I really
don't understand your insistence on doing this.

The fact that this C compiler worked before and does not do now is not
"bait and switch", no one ever guaranteed that this C compiler would work
for building GNAT. THe fact that it did before does not mean it will continue
to do so. 

We certainly can't have a rule in the GNAT compiler that says that you
can't use exceptions because Zack may try to compile the compiler with a
C compiler that does not properly support longjmp/setjmp. How far would
this go? Do you expect GNAT to be able to be bootstrapped with arbitrarily
broken C compilers?

There was *never* an "official word" that you could bootstrap GNAT using
the 2.95 C compiler, I don't quite know where you got that viewpoint. I
guess we will try to make it clearer in future that the recommended procedure
for bootstrapping GNAT is to use the C compiler that we supply precisely for
this purpose, and precisely to insulate the process from the vagaries of
using random C compilers that may not be able to handle the GNAT code.