Comment by Onavo

1 month ago

They can just fork off the Golang frontend and it would be the same, maybe patch the runtime a bit.

Being an old dog, as I mention elsewhere, I see a pattern with gcj.

GCC has some rules to add, and keep frontends on the main compiler, instead of additional branches, e.g. GNU Pascal never got added.

So if there is no value with maintenance effort, the GCC steering will eventually discuss this.

Does gcc even support go?

  • Until a few years ago, gccgo was well maintained and trailed the main Go compiler by 1 or 2 releases, depending on how the release schedules aligned. Having a second compiler was considered an important feature. Currently, the latest supported Go version is 1.18, but without Generics support. I don't know if it's a coincidence, but porting Generics to gccgo may have been a hurdle that broke the cadence.

    • The best thing about gccgo is that it is not burdened with the weirdness of golang's calling convention, so the FFI overhead is basically the same as calling an extern function from C/C++. Take a look at [0] and see how bad golang's cgo calling latency compare to C. gccgo is not listed there but from my own testing it's the same as C/C++.

      [0]: https://github.com/dyu/ffi-overhead

      2 replies →

    • Seems doubtful, given that generics and the gccgo compiler were both spearheaded by Ian Lance Taylor, it seems more likely to me that him leaving google would be a more likely suspect, but I don't track go.

      1 reply →