Why gccgo?

<p>Anyone using gccgo? What advantages it has over gc?</p> <hr/>**评论：**<br/><br/>sh41: <pre><p>I don&#39;t use it much, but I&#39;m still glad it exists. It helps by being a sanity check for gc, making sure they both implement the documented specification, rather than a single implementation becoming the specification.</p> <p>I did use it once to confirm a compiler bug was gc-only and not present in either of gccgo nor GopherJS compilers, which was neat.</p></pre>computesomething: <pre><p>Haven&#39;t used it in quite a while, I think the main reason to maintain a Go frontend for GCC is that it supports more platforms than gc.</p> <p>Another potential benefit is that GCC supports a wider range of optmizations, despite this GCC mostly did worse than gc when I benchmarked it (quite some time ago), from what I read this was likely due to gccgo lacking escape analysis.</p> <p>However, in GCC 7 there is experimental support for this optimization enabled with &#39;-fgo-optimize-allocs&#39; , so there&#39;s a good chance that it will generate faster code than gc in more cases now, I have yet to give it a try myself, perhaps someone else has ?</p></pre>Ainar-G: <pre><p>I don&#39;t personally use it much, but from what I&#39;ve heard GCC might have better optimisations, especially for numeric code.</p> <p>By the way, does anybody know if gccgo still uses thread-per-goroutine model?</p></pre>ragefacesmirk: <pre><p>At one point it was far faster... It also used a thread per go routine, though I don&#39;t know if that&#39;s still true.</p></pre>ChristophBerger: <pre><blockquote> <p>It also used a thread per go routine</p> </blockquote> <p>That&#39;s not an advantage if you ask me...</p></pre>joushou: <pre><p>GCC (and LLVM for that matter) is in an entirely different league of compilers than the GC toolchain (the official compiler).</p> <p>GC is meant to compile <em>very</em> fast, have okay-ish optimisations and a good runtime.</p> <p>GCC (and LLVM) is meant to knock your socks off in the optimisation department at the cost of compilation speed, but due to gccgo not being a big project, the runtime and frontend are a bit lacking, which might give some performance issues.</p></pre>a_k_w: <pre><p>the problem lies within the license and CLA.</p> <p>What needs to be done is for someone to create a new Go frontend for gcc.</p></pre>ratatask: <pre><p>What problem with the license ?</p></pre>a_k_w: <pre><p>google-style 3 clause bsd paired with the CLA is open source suicide. The CLA stripes all rights from its contributors. There is a reason google projects have very little contributions outside of google. EXAMPLE:The closed source version of Go for app engine benefits from EVERYONES hard work, yet google exploits the CLA, and hides this code to itsself, practically robbing the open source community. Sure anyone could take the bsd source and fork it, but then when you try to sell it, you can only copyright your changes. Google uses the CLA to get around that problem, so now all contributions can be re-licensed and sold to the highest bidder. The use of the bsd paired with the CLA grants google rights not extended to all.</p></pre>itsmontoya: <pre><p>I would love more llvm support for go</p></pre>hey_bros_its_gerry: <pre><p>Can you still use C libraries with the gc?</p></pre>sidharth_k: <pre><p>Yes, through something called cgo.</p></pre>