5 ms·

GNU Compiler Collection 4.6.0 released with Go programming language support

120 points by Tsiolkovsky 16y ago

scrod 16y ago
>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 16y ago
  Meanwhile Apple is moving away to LLVM and Clang.
  - cageface 16y ago
    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.
- pohl 16y ago
  No C blocks, alas.
  - anacrolix 16y ago
    C blocks? Please explain!
evangineer 16y ago
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.
pepsi_can 16y ago
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?
- moondowner 16y ago
  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 http://golang.org/doc/devel/release.html to see if a backward-incompatible change has been released.
- michaelcampbell 16y ago
  > 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.
  - deleted 16y ago
    [deleted]
- shailesh 16y ago
  Ian Lance Taylor, contributor of the GCC Go frontend addresses the same concern, in http://www.airs.com/blog/archives/448 http://www.airs.com/blog/archives/448 Basically, yes, it'll be increasingly out of date. Edit: clarity.
alec 16y ago
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 16y ago
  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 16y ago
    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)
old-gregg 16y ago
Does this mean that Go will finally support shared libraries as a compilation target?
russell_h 16y ago
Anyone know if goroutines are still implemented as native POSIX threads in gccgo?
- edsrzf 16y ago
  Yes, they are.
- obiterdictum 16y ago
  Yes and no. They do use a thread pool of OS threads, but they don't map 1-to-1 to goroutines.
  - edsrzf 16y ago
    That's true for the gc compilers, but not for gccgo (yet, anyway). Each go statement in gccgo creates a pthread.
zmmmmm 16y ago
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.

120 points by Tsiolkovsky 16y ago

scrod 16y ago

>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 16y ago
Meanwhile Apple is moving away to LLVM and Clang.
- cageface 16y ago
  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.
pohl 16y ago
No C blocks, alas.
- anacrolix 16y ago
  C blocks? Please explain!

evangineer 16y ago

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.

pepsi_can 16y ago

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?

moondowner 16y ago
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 http://golang.org/doc/devel/release.html to see if a backward-incompatible change has been released.
michaelcampbell 16y ago
> 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.
- deleted 16y ago
  [deleted]
shailesh 16y ago
Ian Lance Taylor, contributor of the GCC Go frontend addresses the same concern, in http://www.airs.com/blog/archives/448 http://www.airs.com/blog/archives/448 Basically, yes, it'll be increasingly out of date. Edit: clarity.

alec 16y ago

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 16y ago
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 16y ago
  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)

old-gregg 16y ago

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

russell_h 16y ago

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

edsrzf 16y ago
Yes, they are.
obiterdictum 16y ago
Yes and no. They do use a thread pool of OS threads, but they don't map 1-to-1 to goroutines.
- edsrzf 16y ago
  That's true for the gc compilers, but not for gccgo (yet, anyway). Each go statement in gccgo creates a pthread.

zmmmmm 16y ago

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.