Many people have this impression, seemingly. I do not. I find that, for c, compared with clang, gcc compiles faster, gives better diagnostics, and generates code of comparable quality. IMO, it is the only good gnu/redhat product.
(I am given to understand that clang has better diagnostics and standard support for c++. I avoid c++ like the plague, so I cannot speak to that.)
As I understand, GCC generated better code than Clang for C++ for a very long time. Inlining is more important for C++ than C, and GCC had a better inliner, not just due to better tuning, but due to better architecture. LLVM fixed its architecture (see The New Pass Manager, GCC basically always had this) and I think it is now competitive in 2020s, but it wasn’t in 2010s.
GCC’s inlined was not necessarily better, it simply worked in the opposite direction. One worked top down, the other bottom up (I forget which is which). This led to different failure modes and, importantly, did much worse on code that had been tweaked to perform well with GCC. LLVM dog foods a lot of these optimisations and the LLVM codebase itself is a large C++ project.
The new pass manager does not change the inlining policy.
I believe LLVM has at least one. I remember reviewing some of the patches 6-7 years ago, not sure when they landed. I don’t remember if either of the outliners landed in tree.
This is my approach if I need to write C. Multiple compilers, fuzzing, testing, asan and others, some static analyser. Then I’m semi-confident that the very basic issues are caught…
Because this is going to change - one thing will be caught by clang, another by gcc.
Yup, this is full of gotchas. For example, the memcmp comparison would be invalid if the struct had padding, and neither gcc nor clang warn about that. It’s mind-boggling that C doesn’t have any syntax to compare structs properly in a non-tedious way.
I’ve definitely had similar situations with C++, where MSVC and GCC were as useless as human brains while clang instantly made it obvious what the error was.
Many people have this impression, seemingly. I do not. I find that, for c, compared with clang, gcc compiles faster, gives better diagnostics, and generates code of comparable quality. IMO, it is the only good gnu/redhat product.
(I am given to understand that clang has better diagnostics and standard support for c++. I avoid c++ like the plague, so I cannot speak to that.)
As I understand, GCC generated better code than Clang for C++ for a very long time. Inlining is more important for C++ than C, and GCC had a better inliner, not just due to better tuning, but due to better architecture. LLVM fixed its architecture (see The New Pass Manager, GCC basically always had this) and I think it is now competitive in 2020s, but it wasn’t in 2010s.
GCC’s inlined was not necessarily better, it simply worked in the opposite direction. One worked top down, the other bottom up (I forget which is which). This led to different failure modes and, importantly, did much worse on code that had been tweaked to perform well with GCC. LLVM dog foods a lot of these optimisations and the LLVM codebase itself is a large C++ project.
The new pass manager does not change the inlining policy.
Doesn’t gcc have a partial inliner?
I do recall hearing that gcc and llvm are both fastest when self-compiled, a fact which will eternally tickle my fancy.
I believe LLVM has at least one. I remember reviewing some of the patches 6-7 years ago, not sure when they landed. I don’t remember if either of the outliners landed in tree.
This is my approach if I need to write C. Multiple compilers, fuzzing, testing, asan and others, some static analyser. Then I’m semi-confident that the very basic issues are caught…
Because this is going to change - one thing will be caught by clang, another by gcc.
If the goal is to catch errors at compile time, C might not be the optimal choice, compared to ie. Zig (which includes a C compiler).
I mean,
zig ccis just a Clang wrapper, so it’s not going to get you better errors.That wasn’t the point that xyproto was making.
Yup, this is full of gotchas. For example, the
memcmpcomparison would be invalid if the struct had padding, and neither gcc nor clang warn about that. It’s mind-boggling that C doesn’t have any syntax to compare structs properly in a non-tedious way.It’s also worth using many many static and dynamic analyzers.
I’ve definitely had similar situations with C++, where MSVC and GCC were as useless as human brains while clang instantly made it obvious what the error was.
You can of course avoid this particular typo by writing
which IMO is cleaner