Add build-many-glibcs.py support for building more GCC libraries.

Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.

glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.

Note that I do not intend to run a build-many-glibcs.py bot with this
new option.  If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).

Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.

Tested by running build-many-glibcs.py with the new option, with
mainline GCC.  There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:

* mips64 / mips64el (all configuration): ICE building libstdc++, as
  seen without using the new option
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.

* aarch64_be: error building libgo (little-endian aarch64 works fine):

version.go:67:13: error: expected ';' or ')' or newline
67 |   BigEndian =
   |             ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 |   BigEndian =
   |   ^

* arm (all configurations): error building libgo:

/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 |  if randomTrap == 0 {
   |     ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 |  r1, _, errno := syscall.Syscall(randomTrap,
   |                                  ^

What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe.  Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.

* armeb (all configurations): error building libada (for some reason
  the Arm libada configuration seems to do different things for EH for
  big-endian, which makes no sense to me and doesn't actually work):

a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"

* hppa: error building libgo (same error as for aarch64_be).

* ia64: ICE building libgo.  I've filed
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.

* m68k: ICE in the Go front end building libgo
  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.

* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
  for lack of a libada port to those systems (I'm not sure sh3 would
  actually need anything different from sh4):

a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47

* i686-gnu: build failure in libada, might be fixed by the patch
  attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
  (not tested):

terminals.c:1115:13: fatal error: termio.h: No such file or directory

	* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
	argument.
	(Config.build_gcc): Use --disable-libsanitizer for first GCC
	build, but not for second build if --full-gcc.  Use
	--enable-languages=all for second build if --full-gcc.
	(get_parser): Add --full-gcc option.
	(main): Update call to Context.

1 files changed, 10 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index e0c9c39d2c..7ec115f588 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2018-09-11  Joseph Myers  <joseph@codesourcery.com>
+
+	* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
+	argument.
+	(Config.build_gcc): Use --disable-libsanitizer for first GCC
+	build, but not for second build if --full-gcc.  Use
+	--enable-languages=all for second build if --full-gcc.
+	(get_parser): Add --full-gcc option.
+	(main): Update call to Context.
+
 2018-09-10  Rafal Luzynski  <digitalfreak@lingonborough.com>
 
 	[BZ #10797]