> Right now Go does not build on a range of targets, notably including > Windows, MacOS, AIX, and most embedded systems. We would have to > disable it by default on targets that are not supported, which is > straightforward (we already have rules to disable java on targets it > does not support). But to the extent that there are options like > -fnon-call-exceptions that are tested primarily by Java and Go, we > would get less coverage of those options, since we would not test them > on systems that Java supports but Go does not.
Let me make the case for Ada here: it's a general purpose, highly portable language, which is regularly built and tested on a significant range of platforms (I personally test it on x86/Linux, x86-64/Linux, PowerPC/Linux, IA-64/Linux, SPARC/Solaris and SPARC64/Solaris). It exercices some features of the compiler that aren't exercised by other languages and stretches some common features much more than the other languages. It turns out that it also enables -fnon-call-exceptions by default. It seamlessly works with LTO. While the fact that a big part of the front-end is written in Ada could be seen as an annoyance (although GNAT has been largely available for about a decade on many systems), it can also be seen a boon; for example, a LTO bootstrap with Ada enabled really exercises cross-language optimizations. Bootstrapping with Ada is marginally slower than with Go (a few percents) and the testsuite is small (4-way parallelizable, testing time of 6 minutes on a fast machine). > More seriously, the Go sources live in a separate repository, and are > copied to the GCC repo. In practice this means that when Go breaks, > it can't be fixed until I am online to fix it. I don't think it would > be good for GCC for a bootstrap break to depend on me. In contrast to that, the FSF repository is the master repository for GNAT and breakages can be quickly fixed by anyone with write access. -- Eric Botcazou
