

GNU Compiler Collection 4.6.0 released with Go programming language support - Tsiolkovsky
http://gcc.gnu.org/gcc-4.6/

======
pepsi_can
Since Go is still in development and with updates being released regularly,
does this mean that the GCC GO compiler implements a specific version of Go
and will be out of date soon?

~~~
michaelcampbell
> does this mean that the GCC GO compiler implements a specific version of Go
> and will be out of date soon?

Unless the gcc team is prescient, I don't see how any other conclusion can be
drawn.

------
old-gregg
Does this mean that Go will finally support shared libraries as a compilation
target?

------
evangineer
From the GCC 4.6.0 release notes:

 _> Support for the Go programming language has been added to GCC. It is not
enabled by default when you build GCC; use the --enable-languages configure
option to build it. The driver program for compiling Go code is gccgo.

>Go is currently known to work on GNU/Linux and RTEMS. Solaris support is in
progress. It may or may not work on other platforms._

------
russell_h
Anyone know if goroutines are still implemented as native POSIX threads in
gccgo?

~~~
obiterdictum
Yes and no. They do use a thread pool of OS threads, but they don't map 1-to-1
to goroutines.

~~~
edsrzf
That's true for the gc compilers, but not for gccgo (yet, anyway). Each go
statement in gccgo creates a pthread.

------
alec
The link-time optimizations seem useful - not only can the output code run
faster, but the compilation is in parallel. Has anyone tried it? g++ is a fast
compiler and it's easy to parallelize on files, but making the linker
faster/parallel sounds like a big deal.

~~~
koenigdavidmj
That's not what LTO is about. Most optimisations up to this point do not cross
function boundaries, or file boundaries if you are lucky. This does better,
allowing optimisations to be applied across the whole program.

~~~
malkia
Alternatively you can go "amalgated" (luajit, juce, and other projects do it).
It's also called "unity" build (in game developer slang).

It's not the same, because two .cpp files concatenated into one should work as
they were before being split (so careful on reusing static variable names,
macro defines, etc.)

Also "amalgated", "unity" builds tend to make the compiler use way more
memory, and reduces the possibility of spreading the compilation across many
processes. Granted that latter thing is a bit of a problem by itself - for
example MSVC's LTCG (Link-Time Code Generation - a whole program optimization)
just produces some intermediate code in the .obj files, and maybe produces it
way faster than generating real cpu code.... Then the linker takes it all and
has to produce it (significantly slower linker times).

With amalgated builds, at least you can divide your big project into 8 or 16
files, that compile on 8-16 processes.

(JUCE splits it in four for example)

------
zmmmmm
I wonder if this opens a path for Windows support for Go (if only through
Cygwin). I'd love to try Go out but the projects I have in mind need to be
able to run (somehow) on Windows.

------
scrod
> _A number of Objective-C 2.0 features and extensions are now supported by
> GCC. These features are enabled by default; you can disable them by using
> the new -fobjc-std=objc1 command-line option._

This seems like a much more important announcement. Apple had been maintaining
these features in their own branch of GCC for years and years, so it's
noteworthy to see them finally merged/added to the official GCC distribution.

~~~
rimantas
Meanwhile Apple is moving away to LLVM and Clang.

~~~
cageface
So far I've had nothing but positive experiences with the LLVM and Clang
integration in XCode 4.0. After almost ten years of relying on GCC this feels
almost like cheating on a spouse.

