4 ms·

Despite many technical reasons, I think license is also one of the biggest motivations.

kstrauser 8y ago
How so? GCC can (and is) used to compile all sorts of proprietary software. I can't imagine a scenario where its license would be any kind of an issue with the toolchain of a Free project.
- craftkiller 8y ago
  GCC was intentionally designed to be hard to extend with proprietary extensions (there's an email from RMS somewhere explicitly stating that) Whereas llvm/clang was designed as a library to be open and extensible, which lead to a lot of tooling being built around it. Unrelated to license, clang also has far better error messages than gcc.
  - loeg 8y ago
    > clang also has far better error messages than gcc. This was true a number of years ago, but I believe GCC's diagnostics have gotten much better in response to competition and don't believe it to be true anymore (although my experience is with C code, not C++ — maybe Clang is better there). Another distinction is that GCC continues to hold a significant lead in producing accurate debuginfo, which is invaluable to me as a developer.
    - lorenzhs 8y ago
      I think both compilers give good error messages (C++14 and C++17). Sometimes one is clearer, sometimes the other, so what I usually do if I can't immediately figure out what the compiler is complaining about is to try the other one and see if that clears things up or at least narrows it down a bit. Works surprisingly often :)
- hubicka 8y ago
  GCC was designed to be extensible and portable (after all it ended up ported to more architectures than any other compiler). The political limitation was more subtle. Originally FSF did not want to make it easy let GCC store its intermediate language and read it back. That was because it would let others to build proprietary frontends and back-ends which is against RMS' vision. This has changed and LTO does precisely that (and indeed in addition to technical difficulties this political issue delayed its arrival in GCC). So this political block of extensibility is long gone (and I am happy for that). A lot has changed in compilation between mid 1980's GCC was started and early 2000's. LLVM design reflects its time. Almost 20 years passed since that and both projects needs to evolve and develop strategies of doing so.
  - loeg 8y ago
    Regardless of the LTO relaxation, I believe it is still the position of the FSF and GCC that any middleware that links in to GCC itself is GPL-infected. Obviously, this is not the case for LLVM/Clang.
kibwen 8y ago
Though not for Firefox, certainly, whose own codebase is already less permissive and more copyleft (MPL) than LLVM.

How so? GCC can (and is) used to compile all sorts of proprietary software. I can't imagine a scenario where its license would be any kind of an issue with the toolchain of a Free project.

craftkiller 8y ago
GCC was intentionally designed to be hard to extend with proprietary extensions (there's an email from RMS somewhere explicitly stating that) Whereas llvm/clang was designed as a library to be open and extensible, which lead to a lot of tooling being built around it. Unrelated to license, clang also has far better error messages than gcc.
- loeg 8y ago
  > clang also has far better error messages than gcc. This was true a number of years ago, but I believe GCC's diagnostics have gotten much better in response to competition and don't believe it to be true anymore (although my experience is with C code, not C++ — maybe Clang is better there). Another distinction is that GCC continues to hold a significant lead in producing accurate debuginfo, which is invaluable to me as a developer.
  - lorenzhs 8y ago
    I think both compilers give good error messages (C++14 and C++17). Sometimes one is clearer, sometimes the other, so what I usually do if I can't immediately figure out what the compiler is complaining about is to try the other one and see if that clears things up or at least narrows it down a bit. Works surprisingly often :)
hubicka 8y ago
GCC was designed to be extensible and portable (after all it ended up ported to more architectures than any other compiler). The political limitation was more subtle. Originally FSF did not want to make it easy let GCC store its intermediate language and read it back. That was because it would let others to build proprietary frontends and back-ends which is against RMS' vision. This has changed and LTO does precisely that (and indeed in addition to technical difficulties this political issue delayed its arrival in GCC). So this political block of extensibility is long gone (and I am happy for that). A lot has changed in compilation between mid 1980's GCC was started and early 2000's. LLVM design reflects its time. Almost 20 years passed since that and both projects needs to evolve and develop strategies of doing so.
- loeg 8y ago
  Regardless of the LTO relaxation, I believe it is still the position of the FSF and GCC that any middleware that links in to GCC itself is GPL-infected. Obviously, this is not the case for LLVM/Clang.

kibwen 8y ago

Though not for Firefox, certainly, whose own codebase is already less permissive and more copyleft (MPL) than LLVM.