6 ms·

I hope gcc remains the default in Linux due to the GPL. But I expect someday clang will become the default. Plus I heard COBOL was merged in with the compiler

by jmclnx 2y ago

I hope gcc remains the default in Linux due to the GPL. But I expect someday clang will become the default. Plus I heard COBOL was merged in with the compiler collection, nice!

mort96 2y ago
GCC can honestly only blame itself for its inevitable increasing obsolescence. LLVM only has the attention it has because it can be used as a building block in other compilers. GCC could've made a tool and library which accepts IR, performs optimizations and emits machine code, but the project avoided that for ideological reasons, and as a result created a void in the ecosystem for a project like LLVM.
- Tpt 2y ago
  There is now libgccjit that aims at allowing to embed gcc https://gcc.gnu.org/onlinedocs/jit/ https://gcc.gnu.org/onlinedocs/jit/ There is an alternative backend to rustc that relies on it.
  - aengelke 2y ago
    libgccjit is, despite its name, just another front-end for GIMPLE. The JIT-part is realized through compiling the object file to a shared library and using dlopen on this. One big problem with libgccjit, despite its fairly bad compile-time performance, is that it's GPL-licensed and thereby makes the entire application GPL, which makes it impossible to use not just in proprietary use-cases but also in cases where incompatible licenses are involved.
- pjmlp 2y ago
  The embedded compiler vendors, UNIX and consoles are quite happy with it. How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?
  - mort96 2y ago
    Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.
    - pjmlp 2y ago
      And FOSS folks most likely would like to enjoy those patches as well on their installations.
      - School-Cotton 2y ago
        And they do! You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them. It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM...
        trelane 2y ago
        > You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them. They contribute some things, sure. But the also don't contribute some things. It is hard to know how much because it's kept secret from all of us, even their own customers. > "It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM..." Rust no, hut there are a lot of proprietary, semi-incompatible proprietary forks out there.
      - mort96 2y ago
        I haven't advocated for re-licensing GCC to be permissively licensed. And patching GCC is necessarily going to be much easier for vendors than to build a new C front-end which generates GCC IR. So I'm not sure what difference you think what I'm proposing would make with regard to your concerns.
    - vbezhenar 2y ago
- dralley 2y ago
  Yet another reason why I'm not a fan of Richard Stallman. Most of the decisions he made over the past 25 years have been self-defeating and led directly to the decline of the influence of his own movement. It's not that "the GCC project" avoided that for ideological reason, Stallman was personally a veto on that issue for years, and his personal objection led to several people quitting the project for LLVM, with a couple saying as much directly to him. https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00091.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... (both threads are interesting reading in their entirety, not just those specific emails)
  - knowknow 2y ago
    Kind like how GPL 3 makes it infeasible for most companies to use/support free software. At least Stallman gets to feel morally superior though
    - dralley 2y ago
      And Free Software does not benefit from a morass of mutually-incompatible copyleft licenses that may as well have been proprietary since you can't use them together. None of the permissive licenses have this problem.
      - gkbrk 2y ago
        Which open-source licenses can't be used together?
        dralley 2y ago
        GPLv2 and GPLv3, for one example... It's sad when two licenses from the same organization are incompatible. GPLv2 and Apache.
        teddyh 2y ago
- codeshaunted 2y ago
  Is it still the case that the Linux kernel cannot be compiled using clang, or can you do that now?
  - bombcar 2y ago
    I believe clang has worked for years now.
    - codeshaunted 2y ago
      Why would anyone bother with GCC then? :P
      - bombcar 2y ago
        I believe GCC still wins by far on support for weird CPUs and embedded systems.
        codeshaunted 2y ago
        With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.
        jcranmer 2y ago
        I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.
        mort96 2y ago
        Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.
- aengelke 2y ago
  I'd add code quality as a reason. I find it much easier to understand and modify code in LLVM compared to GCC. Both have a fairly steep learning curve and not too much documentation, but often I (personally) find LLVM's architecture to be more thought out and easier to understand. GCC's age shows in the code base and it feels like many concepts and optimizations are just bolted on without "required" architectural changes for a proper integration.
pxc 2y ago
> I expect someday clang will become the default [compiler for the Linux kernel]. Why? I don't personally use GCC except to compile other people's projects in a way that's mostly invisible to me, but it seems like it's still widely used and constantly improving, thanks in part to competition with LLVM/Clang. Is the situation really so dire?
- wahern 2y ago
  > Is the situation really so dire? I for one don't think so. From my perspective, there's at least as much momentum in GCC as clang/LLVM, especially on the static analysis and diagnostics front over the past 5 or so years. That was originally one of the selling points for clang, and GCC really took it to heart. It's been 10 years since GCC adopted ASAN, and after playing catchup GCC never stopped upping their game. Perhaps the image problem is that LLVM seems to be preferred more often for interesting research projects, drawing more eyeballs. But by and large these are ephemeral; the activity is somewhat illusory, at least when comparing the liveliness of the LLVM and GCC communities. For example, both clang/LLVM and GCC have seen significant work on addressing array semantics in the language, as part of the effort to address buffer overflows and improve static analysis. But GCC is arguably farther along in terms of comprehensive integration, with a clearer path forward, including for ISO standardization. More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger.
  - pxc 2y ago
    > More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger. You're right to note that "competition" here is more like inspiration than a deathmatch. But I vaguely remember two things that seem similar to motivation via competitive pressure to me: (1) when GCC 5 came out, it had way nicer error messages, and I immediately thought "Oh, they wanted to make GCC nice like Clang" and (2) IIRC the availability of a more modular compiler stack like LLVM/Clang essentially neutralized Stallman's old strategic argument against more a more pluggable design, right?
enasterosophes 2y ago
Unless you're talking about a compiler built into the kernel, I don't see that anyone is in a position to dictate to each distro what compilers they package.
ahartmetz 2y ago
Clang: - has about the same quality of error messages as GCC now - is now almost exactly as slow (/fast) as GCC at compiling now - sometimes produces faster code than Clang, sometimes slower, about the same overall I see no reason why the default would change.
- almostgotcaught 2y ago
  well for one clang uses way less memory (RAM). also ld.lld is wayyyyyyyy faster than ld (and also uses way less memory).
  - ahartmetz 2y ago
    ld.lld works with any compiler, and anyway, mold is even faster and also works with any compiler.
jklowden 2y ago
Yup, COBOL is that overnight sensation 4 years in the making. GCC COBOL is foremost an ISO COBOL compiler, with some extensions for IBM and MicroFocus syntax. We also extended gdb to recognize COBOL, so the GCC programmer has native COBOL compilation and source-level debugging.

by jmclnx 2y ago

I hope gcc remains the default in Linux due to the GPL. But I expect someday clang will become the default. Plus I heard COBOL was merged in with the compiler collection, nice!

mort96 2y ago

GCC can honestly only blame itself for its inevitable increasing obsolescence. LLVM only has the attention it has because it can be used as a building block in other compilers. GCC could've made a tool and library which accepts IR, performs optimizations and emits machine code, but the project avoided that for ideological reasons, and as a result created a void in the ecosystem for a project like LLVM.

Tpt 2y ago
There is now libgccjit that aims at allowing to embed gcc https://gcc.gnu.org/onlinedocs/jit/ https://gcc.gnu.org/onlinedocs/jit/ There is an alternative backend to rustc that relies on it.
- aengelke 2y ago
  libgccjit is, despite its name, just another front-end for GIMPLE. The JIT-part is realized through compiling the object file to a shared library and using dlopen on this. One big problem with libgccjit, despite its fairly bad compile-time performance, is that it's GPL-licensed and thereby makes the entire application GPL, which makes it impossible to use not just in proprietary use-cases but also in cases where incompatible licenses are involved.
pjmlp 2y ago
The embedded compiler vendors, UNIX and consoles are quite happy with it. How much do you think they contribute back upstream regarding ISO compliance outside LLVM backend for their hardware and OS?
- mort96 2y ago
  Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.
  - pjmlp 2y ago
    And FOSS folks most likely would like to enjoy those patches as well on their installations.
    - School-Cotton 2y ago
      And they do! You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them. It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM...
      - trelane 2y ago
        > You can choose not to contribute your changes back to permissively-licensed software, but in actual practice most people do contribute them. They contribute some things, sure. But the also don't contribute some things. It is hard to know how much because it's kept secret from all of us, even their own customers. > "It's not like the Rust compiler is proprietary software with their own closed-source fork of LLVM..." Rust no, hut there are a lot of proprietary, semi-incompatible proprietary forks out there.
    - mort96 2y ago
      I haven't advocated for re-licensing GCC to be permissively licensed. And patching GCC is necessarily going to be much easier for vendors than to build a new C front-end which generates GCC IR. So I'm not sure what difference you think what I'm proposing would make with regard to your concerns.
  - vbezhenar 2y ago
dralley 2y ago
Yet another reason why I'm not a fan of Richard Stallman. Most of the decisions he made over the past 25 years have been self-defeating and led directly to the decline of the influence of his own movement. It's not that "the GCC project" avoided that for ideological reason, Stallman was personally a veto on that issue for years, and his personal objection led to several people quitting the project for LLVM, with a couple saying as much directly to him. https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00091.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... (both threads are interesting reading in their entirety, not just those specific emails)
- knowknow 2y ago
  Kind like how GPL 3 makes it infeasible for most companies to use/support free software. At least Stallman gets to feel morally superior though
  - dralley 2y ago
    And Free Software does not benefit from a morass of mutually-incompatible copyleft licenses that may as well have been proprietary since you can't use them together. None of the permissive licenses have this problem.
    - gkbrk 2y ago
      Which open-source licenses can't be used together?
      - dralley 2y ago
        GPLv2 and GPLv3, for one example... It's sad when two licenses from the same organization are incompatible. GPLv2 and Apache.
        teddyh 2y ago
codeshaunted 2y ago
Is it still the case that the Linux kernel cannot be compiled using clang, or can you do that now?
- bombcar 2y ago
  I believe clang has worked for years now.
  - codeshaunted 2y ago
    Why would anyone bother with GCC then? :P
    - bombcar 2y ago
      I believe GCC still wins by far on support for weird CPUs and embedded systems.
      - codeshaunted 2y ago
        With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.
        jcranmer 2y ago
        I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.
        mort96 2y ago
        Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.
aengelke 2y ago
I'd add code quality as a reason. I find it much easier to understand and modify code in LLVM compared to GCC. Both have a fairly steep learning curve and not too much documentation, but often I (personally) find LLVM's architecture to be more thought out and easier to understand. GCC's age shows in the code base and it feels like many concepts and optimizations are just bolted on without "required" architectural changes for a proper integration.

pxc 2y ago

> I expect someday clang will become the default [compiler for the Linux kernel]. Why? I don't personally use GCC except to compile other people's projects in a way that's mostly invisible to me, but it seems like it's still widely used and constantly improving, thanks in part to competition with LLVM/Clang. Is the situation really so dire?

wahern 2y ago
> Is the situation really so dire? I for one don't think so. From my perspective, there's at least as much momentum in GCC as clang/LLVM, especially on the static analysis and diagnostics front over the past 5 or so years. That was originally one of the selling points for clang, and GCC really took it to heart. It's been 10 years since GCC adopted ASAN, and after playing catchup GCC never stopped upping their game. Perhaps the image problem is that LLVM seems to be preferred more often for interesting research projects, drawing more eyeballs. But by and large these are ephemeral; the activity is somewhat illusory, at least when comparing the liveliness of the LLVM and GCC communities. For example, both clang/LLVM and GCC have seen significant work on addressing array semantics in the language, as part of the effort to address buffer overflows and improve static analysis. But GCC is arguably farther along in terms of comprehensive integration, with a clearer path forward, including for ISO standardization. More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger.
- pxc 2y ago
  > More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger. You're right to note that "competition" here is more like inspiration than a deathmatch. But I vaguely remember two things that seem similar to motivation via competitive pressure to me: (1) when GCC 5 came out, it had way nicer error messages, and I immediately thought "Oh, they wanted to make GCC nice like Clang" and (2) IIRC the availability of a more modular compiler stack like LLVM/Clang essentially neutralized Stallman's old strategic argument against more a more pluggable design, right?

enasterosophes 2y ago

Unless you're talking about a compiler built into the kernel, I don't see that anyone is in a position to dictate to each distro what compilers they package.

ahartmetz 2y ago

Clang: - has about the same quality of error messages as GCC now - is now almost exactly as slow (/fast) as GCC at compiling now - sometimes produces faster code than Clang, sometimes slower, about the same overall I see no reason why the default would change.

almostgotcaught 2y ago
well for one clang uses way less memory (RAM). also ld.lld is wayyyyyyyy faster than ld (and also uses way less memory).
- ahartmetz 2y ago
  ld.lld works with any compiler, and anyway, mold is even faster and also works with any compiler.

jklowden 2y ago

Yup, COBOL is that overnight sensation 4 years in the making. GCC COBOL is foremost an ISO COBOL compiler, with some extensions for IBM and MicroFocus syntax. We also extended gdb to recognize COBOL, so the GCC programmer has native COBOL compilation and source-level debugging.