3 ms·

> Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. This is wildly offtopic for this thread, but it is no

> Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis. This is wildly offtopic for this thread, but it is not clear that Stallman's stance on this issue was an error. The wide existence of LLVM-based compilers for proprietary architectures is, for many of us, a tragedy that Stallman correctly anticipated. His insightful and courageous steering of the GCC development was a crucial step in avoiding this problem for GCC.

dagmx 6y ago
Isn't it also precluding several non proprietary compilers as well though? In turn making LLVM more popular and making it even more appealing to propriety compiler authors.
mst 6y ago
I definitely believe that for the first N years of gcc the policy was absolutely necessary to drag vendors into actually contributing back. Whether that's still true in terms of the trade-offs being worth it to maintain the policy in the current day, and if it's no longer true what value of N accurately describes when that changed, is something that I think people can reasonably disagree about. (my extremely boring take being "there's so many counterfactuals here I'm really not sure")
dralley 6y ago
At the expense of forcing people that would love to use GCC to produce open-source tools and research, into using LLVM. See the email thread I linked for several such examples. https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00106.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00125.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00088.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00640.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00648.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... Most compiler research and tooling development now happens in the LLVM ecosystem, precisely because they dragged their feet for so long.

dagmx 6y ago

Isn't it also precluding several non proprietary compilers as well though? In turn making LLVM more popular and making it even more appealing to propriety compiler authors.

mst 6y ago

I definitely believe that for the first N years of gcc the policy was absolutely necessary to drag vendors into actually contributing back. Whether that's still true in terms of the trade-offs being worth it to maintain the policy in the current day, and if it's no longer true what value of N accurately describes when that changed, is something that I think people can reasonably disagree about. (my extremely boring take being "there's so many counterfactuals here I'm really not sure")

dralley 6y ago

At the expense of forcing people that would love to use GCC to produce open-source tools and research, into using LLVM. See the email thread I linked for several such examples. https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00106.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00125.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00088.html https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00640.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00648.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... Most compiler research and tooling development now happens in the LLVM ecosystem, precisely because they dragged their feet for so long.