Earlier quoted context omitted.
It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…
GCC still generates faster binaries (on average across a wide set of benchmarks) than clang as of last year
Toward _FORTIFY_SOURCE Parity Between Clang and GCC
11–20 of 30 posts
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#12Is it good for both, Pareto optimal, or is it bad for GCC that Clang is catching up? But if Clang is catching up, is that really bad?
Good for everybody to have a non-monoculture and some friendly competition.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#13Earlier quoted context omitted.
It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…
GCC still generates faster binaries (on average across a wide set of benchmarks) than clang as of last year
https://www.phoronix.com/scan.php?page=article&item=gcc9-cla...
https://medium.com/@alitech_2017/gcc-vs-clang-llvm-an-in-dep...
Remember that these are both Linux benchmarks; GCC on windows is a bit sketchy with MinGW. Things can usually be made to work, but Clang is the only real competitor to MSVC (unless you're counting Intel's crazy-expensive offering, which is not intended for general use).
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#14Earlier quoted context omitted.
Given both are open source, neither of them is going to be able to leapfrog the other for long, at least in terms of core C/C++ language features, without the other copying and implementing something similar. Both have sufficient developers to keep up with the pace of development. What's more interesting, at least to me, is what impact this competition is having on the wider ecosystem. Is it leading to more features…
> Is it leading to more features and better compilation than would be the case if there was just one compiler toolchain? I would argue that the pace of C++ compiler development has significantly increased since clang was introduced. I would surmise that elimination of GCC or Clang -- in the way that Chrome has resulted in the elimination of more than one competing browser -- would be detrimental to C++ as a whole. An…
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#15Earlier quoted context omitted.
Given both are open source, neither of them is going to be able to leapfrog the other for long, at least in terms of core C/C++ language features, without the other copying and implementing something similar. Both have sufficient developers to keep up with the pace of development. What's more interesting, at least to me, is what impact this competition is having on the wider ecosystem. Is it leading to more features…
Clang can't copy from GCC due to the different licenses. GCC can't copy from Clang due to the FSF requiring a copyright assignment.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#16Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#17Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#18Is it good for both, Pareto optimal, or is it bad for GCC that Clang is catching up? But if Clang is catching up, is that really bad?
It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#19How does this relate to the address sanitizer? I believe ASan can catch all of the issues caught by _FORTIFY_SOURCE. Does the latter have fewer checks and better runtime performance? I'm guessing it is considered by most to be fine using _FORTIFY_SOURCE in production binaries but too much overhead for ASan?
Edit: there is some overlap, of course.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#20Is it good for both, Pareto optimal, or is it bad for GCC that Clang is catching up? But if Clang is catching up, is that really bad?
It's bad for GCC, but good for C++ developers. GCC and MSVC will die and there will be only one compiler on all platforms (which is also the best one). Just have a look at Chrome and Firefox. They already use Clang on all platforms. On Windows they are working on replacing link with lld. Android has deprecated GCC completely. In the future it's gonna be clang + lld + libc++ all the way. And yeah, GDB and WinDbg will…
This is the longest shot of what you mentioned. I can see a future where the llvm toolchain dominates but people still use GDB because of muscle memory. (Unless LLDB changes its commands to match GDB.)
Also GCC is guaranteed to live for at least 50 yrs because of freetards. GNU has die hard users and developers who would rather die than leave. LLVM has money, big money. It remains to be seen which matters more.