5 ms·

How many C or C++ compilers are in wider use today? Not really working in the area and did not research now, but I can come up with: * gcc * clang * Microso

How many C or C++ compilers are in wider use today? Not really working in the area and did not research now, but I can come up with: * gcc * clang * Microsoft probably has their own implementation * Intel probably still has their own implementation * ? Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use Edit2: ARM of course

shiomiru 2y ago
tcc is popular too, as a fast non-optimizing compiler.
- cenamus 2y ago
  Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
  - mananaysiempre 2y ago
    The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.) [1] https://briancallahan.net/blog/20211010.html https://briancallahan.net/blog/20211010.html
    - cenamus 2y ago
      Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
      - mananaysiempre 2y ago
        Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.
        fuhsnn 2y ago
        I tested with tcc, cparser and my own slimcc, the benchmark showed multiple process with htop, so there are some dynamic cpu scaling randomness going on. I saw larger run-to-run differences with the same binary, than with comparing cherry-picked best-run of each, so probably not the best benchmark.
- usr1106 2y ago
  Fabrice Bellard, unbelievable what a single person can get done.
asplake 2y ago
Per [1], Zig seems to have its own C compiler (AFAICT it's not just a frontend to an existing one) [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- flohofwoe 2y ago
  Currently, zig cc is the Clang frontend which is linked into the Zig compiler (most things in that blog post are about differences between the Zig toolchain and a typical Clang toolchain for cross-compilation, and how Zig invokes the Clang frontend). I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation). [1] https://github.com/Vexu/arocc https://github.com/Vexu/arocc
senkora 2y ago
For C++, there are exactly four independent frontends in wide use (gcc, clang, msvc, edg) and three independent stdlibs (libstdc++, libc++, STL). I’m not sure how many independent compiler backends are widely used with those frontends and stdlibs.
flohofwoe 2y ago
Clang, GCC and MSVC are the big ones, the rest are more or less niche compilers - with Clang and GCC only differing in small details. (one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)
- pjmlp 2y ago
  Depends on how much one considers the game industry niche, where Linux hardly has a role other than game servers.
  - flohofwoe 2y ago
    True of course, but then MSVC only matters for building Windows and Xbox games (and at least on Windows I would also give Clang a try since it typically optimizes better than MSVC).
    - pjmlp 2y ago
      And as IDE for Sony and PlayStation toolchains. While Microsoft has embraced clang as well, including on XBox, I am certain it does not consume all Windows SDKs, not yet.
tliltocatl 2y ago
Probably not qualifies as "wide use" but embedded compilers like SDCC still matters. Yes, 8-bits are giving way to ARM, but there will be a few more millennia before they are out.
jasode 2y ago
>Intel probably still has their own implementation Back in 2021, Intel moved the back end of their compiler toolchain to LLVM . Intel still has their own proprietary front end (icpx). https://www.google.com/search?q=intel+compiler+llvm+adoption https://www.google.com/search?q=intel+compiler+llvm+adoption https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-icc-users-to-dpcpp-or-icx.html https://www.intel.com/content/www/us/en/developer/articles/g...
- gpderetta 2y ago
  Is icpx still and EDG derivative? EDG used to be the gold standard of ISO conformance.
  - usr1106 2y ago
    EDG: 6 employees according to Wikipedia. That's what I call travelling light, not much room for corporate BS there, I bet.
    - gpderetta 2y ago
      They used to be three, all of them members of the committee.
skissane 2y ago
> Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha. For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open... OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard https://docs.vmssoftware.com/vsi-openvms-calling-standard IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.
- usr1106 2y ago
  Good point. I completely forgot IBM. And I even was a trainee there, when mainframes where a big thing, PCs an exception and nobody including myself had heard about AIX (although technically it was a year old).

shiomiru 2y ago

tcc is popular too, as a fast non-optimizing compiler.

cenamus 2y ago
Similarly, cproc with the QBE backend. Focused on simplicity an getting to 80% of gcc/clang with 20% of the complexity/size.
- mananaysiempre 2y ago
  The maintainer of oksh has an interesting comparison[1] between tcc and cproc as it comes to the performance of the generated code on OpenBSD. To be clear, cproc delivers. But tcc beats it, usually significantly, for reasons I can’t even begin to see how to investigate. It actually beats cparser/libfirm in most cases, which just makes no sense. (I ran the benchmarks myself on Linux some months ago; with the versions given in the original post, they reproduce.) [1] https://briancallahan.net/blog/20211010.html https://briancallahan.net/blog/20211010.html
  - cenamus 2y ago
    Those results are truly strange, tcc on the same level as gcc/clang for all tests? Something's going on
    - mananaysiempre 2y ago
      Right?.. There’s a reason I decided to spend the couple of hours it took to get libfirm to compile. Then again, it’s a shell benchmark, most of it is bound to be syscalls and (nonfancy) parsing, so the space for an optimizing compiler to make a difference is bound to be fairly limited. All the compilers in the test are within 2× of the best one, and CompCert isn’t exactly a speed demon either. I’d love to dig into this, but there are so many layers of stuff I don’t really know where to start.
      - fuhsnn 2y ago
        I tested with tcc, cparser and my own slimcc, the benchmark showed multiple process with htop, so there are some dynamic cpu scaling randomness going on. I saw larger run-to-run differences with the same binary, than with comparing cherry-picked best-run of each, so probably not the best benchmark.
usr1106 2y ago
Fabrice Bellard, unbelievable what a single person can get done.

asplake 2y ago

Per [1], Zig seems to have its own C compiler (AFAICT it's not just a frontend to an existing one) [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

flohofwoe 2y ago
Currently, zig cc is the Clang frontend which is linked into the Zig compiler (most things in that blog post are about differences between the Zig toolchain and a typical Clang toolchain for cross-compilation, and how Zig invokes the Clang frontend). I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation). [1] https://github.com/Vexu/arocc https://github.com/Vexu/arocc

senkora 2y ago

For C++, there are exactly four independent frontends in wide use (gcc, clang, msvc, edg) and three independent stdlibs (libstdc++, libc++, STL). I’m not sure how many independent compiler backends are widely used with those frontends and stdlibs.

flohofwoe 2y ago

Clang, GCC and MSVC are the big ones, the rest are more or less niche compilers - with Clang and GCC only differing in small details. (one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)

pjmlp 2y ago
Depends on how much one considers the game industry niche, where Linux hardly has a role other than game servers.
- flohofwoe 2y ago
  True of course, but then MSVC only matters for building Windows and Xbox games (and at least on Windows I would also give Clang a try since it typically optimizes better than MSVC).
  - pjmlp 2y ago
    And as IDE for Sony and PlayStation toolchains. While Microsoft has embraced clang as well, including on XBox, I am certain it does not consume all Windows SDKs, not yet.

tliltocatl 2y ago

Probably not qualifies as "wide use" but embedded compilers like SDCC still matters. Yes, 8-bits are giving way to ARM, but there will be a few more millennia before they are out.

jasode 2y ago

>Intel probably still has their own implementation Back in 2021, Intel moved the back end of their compiler toolchain to LLVM . Intel still has their own proprietary front end (icpx). https://www.google.com/search?q=intel+compiler+llvm+adoption https://www.google.com/search?q=intel+compiler+llvm+adoption https://www.intel.com/content/www/us/en/developer/articles/guide/porting-guide-for-icc-users-to-dpcpp-or-icx.html https://www.intel.com/content/www/us/en/developer/articles/g...

gpderetta 2y ago
Is icpx still and EDG derivative? EDG used to be the gold standard of ISO conformance.
- usr1106 2y ago
  EDG: 6 employees according to Wikipedia. That's what I call travelling light, not much room for corporate BS there, I bet.
  - gpderetta 2y ago
    They used to be three, all of them members of the committee.

skissane 2y ago

> Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha. For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open... OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard https://docs.vmssoftware.com/vsi-openvms-calling-standard IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.

usr1106 2y ago
Good point. I completely forgot IBM. And I even was a trainee there, when mainframes where a big thing, PCs an exception and nobody including myself had heard about AIX (although technically it was a year old).