3 ms·

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

by Onavo 11mo ago

MangoToupe 11mo ago
Does gcc even support go?
- ameliaquining 11mo ago
  Yes, though language support runs behind the main Go compiler. https://go.dev/doc/install/gccgo https://go.dev/doc/install/gccgo
- wahern 11mo ago
  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.
  - ratmice 11mo ago
    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.
    - pjmlp 11mo ago
      This has been stagnant long before he left.
  - syockit 11mo ago
    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 https://github.com/dyu/ffi-overhead
    - wahern 11mo ago
      Isn't that horribly out of date? More recent benchmarks elsewhere performed after some Go improvements show Go's C FFI having drastically lower overheard, by at least an order of magnitude, IIUC.
    - MangoToupe 11mo ago
      > The best thing about gccgo is that it is not burdened with the weirdness of golang's calling convention Interesting. I saw go breaking from the c abi as the primary reason to use it; otherwise you might as well use java or rust.
pjmlp 11mo ago
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.

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

by Onavo 11mo ago

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

MangoToupe 11mo ago

Does gcc even support go?

ameliaquining 11mo ago
Yes, though language support runs behind the main Go compiler. https://go.dev/doc/install/gccgo https://go.dev/doc/install/gccgo
wahern 11mo ago
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.
- ratmice 11mo ago
  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.
  - pjmlp 11mo ago
    This has been stagnant long before he left.
- syockit 11mo ago
  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 https://github.com/dyu/ffi-overhead
  - wahern 11mo ago
    Isn't that horribly out of date? More recent benchmarks elsewhere performed after some Go improvements show Go's C FFI having drastically lower overheard, by at least an order of magnitude, IIUC.
  - MangoToupe 11mo ago
    > The best thing about gccgo is that it is not burdened with the weirdness of golang's calling convention Interesting. I saw go breaking from the c abi as the primary reason to use it; otherwise you might as well use java or rust.

pjmlp 11mo ago

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.