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?

> 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.

Ian Lance Taylor, contributor of the GCC Go frontend addresses the same concern, in http://www.airs.com/blog/archives/448

Basically, yes, it'll be increasingly out of date.

Edit: clarity.

It's a pretty important question and I hope that gccgo will keep up constantly with the newest Go releases (which I know is though because Go has weekly releases).

You can follow their golang-announce mailing list or check this page http://golang.org/doc/devel/release.html to see if a backward-incompatible change has been released.

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

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

Yes, they are.

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

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

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.

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.

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.

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)

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.

>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.

Meanwhile Apple is moving away to LLVM and Clang.

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.

No C blocks, alas.