On Sat, 17 Mar 2012, Graham Anderson wrote:
Sascha, list,
With Go language changes pretty much finished and a Go 1.0 stable release iminent I'd like to progress more with how we support this language. We already have a very good Go compiler in Factory but I would also like to have the gccgo compiler available for 12.2 so that we can offer a great Go hacking environment.
Go currently has two reference implementations of it's spec, the first is the more commonly used {5,6,8}g compiler which is developed with the main Go tree, it's a derivative of Ken Thompson's plan 9 C compiler. The second reference implementation is the gccgo frontend introduced with gcc46 by Ian Taylor (who engineered the gold linker).
The benefits of having both compilers are as follows:
5g, 6g, 8g compilers are *very* fast
but
gccgo compiler generates faster code
also
The language is new, having two reference compilers is great for sanity checks on Go code projects.
Some developers may be more comfortable with a gcc frontend because they use the gcc collection anyway.
Building the gccgo frontend is no problem, however to implement the same parity of concurrency features as the other compiler, gccgo needs to be built with the gold linker.
Go concurrency is based on lightweight threads called goroutines, the goroutines are multiplexed on top of OS threads with each goroutine having their own small initial stack. This is managed by the Go runtime but the compiler and linker must support it.
The version of the gold linker in factory (binutils 2.22) supports segmented stacks however gcc47 is currently built with traditional ld linker.
Since now is the time where we are potentially adopting gcc47 it's also a good time to ask about what I would like to see from it. I can easily build gcc47 on my local OBS with my preference for the gold linker, but it's clear from the .spec.in comments of the gcc package that the compiler testing framework is an internal affair. I would therefore request that an analysis of building gcc with the gold linker was performed on the internal test framework for gcc.
If it's impractical to ask for a change of linker at the same time as a change of gcc version, then by all means say so (note that I'm only asking that gcc be built with gold linker). In which case I can try and maintain a gccgo compiler inside the go language project.
The much bigger issue is that the two Go compilers are not ABI compatible.
So IMHO for openSUSE we have to choose one (though I understand in Go
you are supposed to always re-compile the libraries you use with your
program).
And no, switching the default linker to gold is not a good idea IMHO
given its lack of architecture support for s390 and ia64 (I suppose
only x86 and arm are well-tested, not idea about the powerpc state).
Richard.
--
Richard Guenther