Toward _FORTIFY_SOURCE Parity Between Clang and GCC
developers.redhat.com
Toward _FORTIFY_SOURCE Parity Between Clang and GCC
1–10 of 30 posts
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#2Is 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?
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#3Is 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?
Clang has mostly caught up to GCC and suppressed it in many others ways. It's probably somewhat bad in the long run since LLVM/Clang seems to have more devs contributing to it now.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#4Is 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?
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 and better compilation than would be the case if there was just one compiler toolchain?
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#5Is 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
#6Is 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?
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.
And therefore, I would say: yes, it's leading to more features and better compilation that if it was just one compiler toolchain.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#7Is 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?
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
#8Is 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 also be replaced by LLDB.
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#9Is 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…
GCC still generates faster binaries (on average across a wide set of benchmarks) than clang as of last year
Re: Toward _FORTIFY_SOURCE Parity Between Clang and GCC
#10Earlier 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.
Not literal copying, no, since the two codebases differ substantially, but they can look at the code for what the other has done to see how they did it and they can re-implement it without fear of patent infringement claims.