3 ms·

It's not like GCC or the embedded toolchains are a shining beacon of ISO compliance... and if you mean video game consoles, are any of them using GCC today? Son

by duped 2y ago

It's not like GCC or the embedded toolchains are a shining beacon of ISO compliance... and if you mean video game consoles, are any of them using GCC today? Sony and Nintendo are both LLVM and Microsoft is Microsoft

pjmlp 2y ago
The difference being that vendors forks not compliant with GPL can be legally asked for the changes they haven't sent upstream.
- bluGill 2y ago
  Venders who use llvm quickly discover the cost of mainaining their own fork is too high and end up contributing back.
  - pjmlp 2y ago
    The point was the whole clang package, and no they don't, plenty of examples.
    - LeFantome 2y ago
      Except they do, plenty of examples (many already provided)
      - pjmlp 2y ago
        Examples yes, I provided the examples of everyone taking advantage while not contributing. I am still waiting for the counter examples regarding clang contributions.
        bluGill 2y ago
        Clang is in git with good tracking of who each contributor is - there are more than 4000.
- duped 2y ago
  With LLVM they don't need to fork it in the first place. But still, it doesn't matter because ISO compliance is a frontend problem. The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all. If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"
  - mort96 2y ago
    Forcing vendors to contribute back upstream is an attempt at making vendor toolchains not exist. If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers. With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch. With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch. Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.
    - dzaima 2y ago
      gcc requires that contributors assign copyright to FSF (or at least "certify the Developer Certificate of Origin")[0], so a fork isn't gonna get upstreamed without the approval of the fork's authors. So that limits the benefit from gcc-forks to individuals keeping the fork alive. [0]: https://gcc.gnu.org/contribute.html#legal https://gcc.gnu.org/contribute.html#legal
    - charcircuit 2y ago
      >making it impossible to integrate it back into LLVM Code getting open source is not impossible. Companies do it all of the time because it's expensive to rebase.
uecker 2y ago
GCC has very good ISO compliance and ISO C23 is better supported than in Clang (which I expect to catch up soon though)
- throwaway2037 2y ago
  Knowing the history of GCC (more focused on C) and Clang (more focused on C++), it makes sense to me that GCC has better ISO C compliance. Clang has a very nice specific page for ISO C version compliance: https://clang.llvm.org/c_status.html#c2x https://clang.llvm.org/c_status.html#c2x I could not find the same for GCC, but I found an old one for C99: https://gcc.gnu.org/c99status.html https://gcc.gnu.org/c99status.html CppRef has a joint page, but honestly, I am more likely to believe a page directly owned/controlled/authored by the project itself: https://en.cppreference.com/w/c/compiler_support/23 https://en.cppreference.com/w/c/compiler_support/23 Finally, is there a specific feature of C23 that you need that Clang does not support?
  - uecker 2y ago
    I would not say that GCC is more focused on C. Also in GCC there is a lot more effort going into C++ than C. C is generally neglected, which is sad given its importance. GCC's support for C23 is essentially complete. Clang is mostly catching up, but features I need that I am missing are storage class in compound literals and tag compatibility. It is also sad that Clang does not implement strict aliasing correctly (it applies C++'s rules also in C).
- bobmcnamara 2y ago
  "substantially complete" C99 even

by duped 2y ago

pjmlp 2y ago

The difference being that vendors forks not compliant with GPL can be legally asked for the changes they haven't sent upstream.

bluGill 2y ago
Venders who use llvm quickly discover the cost of mainaining their own fork is too high and end up contributing back.
- pjmlp 2y ago
  The point was the whole clang package, and no they don't, plenty of examples.
  - LeFantome 2y ago
    Except they do, plenty of examples (many already provided)
    - pjmlp 2y ago
      Examples yes, I provided the examples of everyone taking advantage while not contributing. I am still waiting for the counter examples regarding clang contributions.
      - bluGill 2y ago
        Clang is in git with good tracking of who each contributor is - there are more than 4000.
duped 2y ago
With LLVM they don't need to fork it in the first place. But still, it doesn't matter because ISO compliance is a frontend problem. The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all. If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"
- mort96 2y ago
  Forcing vendors to contribute back upstream is an attempt at making vendor toolchains not exist. If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers. With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch. With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch. Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.
  - dzaima 2y ago
    gcc requires that contributors assign copyright to FSF (or at least "certify the Developer Certificate of Origin")[0], so a fork isn't gonna get upstreamed without the approval of the fork's authors. So that limits the benefit from gcc-forks to individuals keeping the fork alive. [0]: https://gcc.gnu.org/contribute.html#legal https://gcc.gnu.org/contribute.html#legal
  - charcircuit 2y ago
    >making it impossible to integrate it back into LLVM Code getting open source is not impossible. Companies do it all of the time because it's expensive to rebase.

uecker 2y ago

GCC has very good ISO compliance and ISO C23 is better supported than in Clang (which I expect to catch up soon though)

throwaway2037 2y ago
Knowing the history of GCC (more focused on C) and Clang (more focused on C++), it makes sense to me that GCC has better ISO C compliance. Clang has a very nice specific page for ISO C version compliance: https://clang.llvm.org/c_status.html#c2x https://clang.llvm.org/c_status.html#c2x I could not find the same for GCC, but I found an old one for C99: https://gcc.gnu.org/c99status.html https://gcc.gnu.org/c99status.html CppRef has a joint page, but honestly, I am more likely to believe a page directly owned/controlled/authored by the project itself: https://en.cppreference.com/w/c/compiler_support/23 https://en.cppreference.com/w/c/compiler_support/23 Finally, is there a specific feature of C23 that you need that Clang does not support?
- uecker 2y ago
  I would not say that GCC is more focused on C. Also in GCC there is a lot more effort going into C++ than C. C is generally neglected, which is sad given its importance. GCC's support for C23 is essentially complete. Clang is mostly catching up, but features I need that I am missing are storage class in compound literals and tag compatibility. It is also sad that Clang does not implement strict aliasing correctly (it applies C++'s rules also in C).
bobmcnamara 2y ago
"substantially complete" C99 even