LINUX.ORG.RU

Широкая дискуссия о будущем GCC

 ,


3

5

В прошедший вторник в список рассылки GCC попало одно письмо, вызвавшее множество ответов и даже интересное обсуждение о будущем GNU Compiler Collection, о его конечных целях и об их достижимости. В первом письме просто был задан вопрос о примерных сроках полной реализации стандарта ISO C++11. Но по мере разрастания нити Diego Novillo из Google, хорошо зарекомендовавший себя в роли разработчика GCC, даже высказал опасения, что GCC уже прошёл точку невозврата и ему грозит естественная смерть.

Нить появилась в списках рассылки во вторник и обновляется по сей день. Также промелькнула ссылка на страницу с отчётом о поддержке C++11 в GCC, но обсуждение ушло в другие области, как то: разработка GCC, привлечение новых разработчиков, выживание ведущего свободного компилятора. А теперь проведём обзор самых интересных комментариев нити.

Дискуссия разгорелась после того, как на резонный вопрос «Когда спецификация C++11 будет полностью воплощена в код?» был получен ответ «Как всегда, не раньше чем добровольцы-ментейнеры воплотят её в код».

Фраза «добровольцы-ментейнеры» в ответе и стала поводом широкого обсуждения о нехватке добровольцев, которые желают (это-то легко) и при этом могут работать над GCC (что намного труднее и удаётся меньшинству). Множество людей, занятых в GCC, участвуют в проекте с незапамятных времён. А сколько кода было написано людьми, пришедшими в 2012 и никогда не работавшими прежде? Стоит рассмотреть такую меру, как улучшение понятности компилятора, посредством, например, больших вложений в проектную документацию. Многие знания о структуре GCC до сих пор остаются лишь в памяти людей, которых в любой день может задавить автобус, перевозящий сотрудников Microsoft.

Затем новым разработчикам, мечтающим о том, чтобы им выпала честь работать над GCC, рекомендовали посетить страницу.

В ответ на предложения по уменьшению входного порога для интересующихся GCC также поступали классические отговорки «Компиляторы — это очень сложные программы» и «едва ли несколько человек хотят и при этом способны написать такую документацию».

Разумеется, были и споры на тему LLVM/Clang. Одним из ответов было «Как вам идея, что Clang влияет на эти сроки, потому что GCC теперь вынужден конкурировать с ним? Clang сейчас немного впереди и GCC должен измениться, если он хочет по-прежнему быть ведущим».

В ответ на это, Diego Novillo, всё ещё работающий в Google, поделился своим мнением:

Я вижу несколько прикладных областей, с которыми Clang/LLVM успешно справляется и в которых GCC, на мой взгляд, пока не стремится участвовать: в частности, «инструментабельность» (toolability), за неимением лучшего слова. Архитектурный дизайн clang следует пути, отличному от g++. Это не просто кодогенерирующий парсер, это прежде всего парсер, который помимо прочего генерирует код (прим. переводчика - см. SemaCodeComplete.cpp в исходниках clang, в т.ч. где вызываются эти функции). Это различие позволяет использовать компилятор в инструментах любого рода, которым нужно знать о семантике C++: в статических анализаторах, при форматировании кода, подсветке синтаксиса и т.д. Вдобавок он реализован как библиотека и может встраиваться в приложения.

Это задачи, которые g++ сейчас не может выполнить. С помощью плагинов он, конечно, может выполнить кое-что из перечисленного, но эти плагины куда сложнее и вынуждены влезать в недра компилятора.

Не факт, что всё это является недостатком g++. Но для эффективной конкуренции в этих областях необходима существенная реорганизация.

LLVM имеет схожие с clang свойства. GCC всё ещё имеет некоторые ограничения в портируемости своих бекендов.

Примечательно и другое письмо про необходимость притока свежих сил из числа молодых студентов и университетских исследователей, которые на данный момент почти повсеместно используют LLVM (прим. переводчика — подтверждаю, и в российских ВУЗах LLVM вытеснил MSIL). В ответ на него уже известный вам Diego Novillo создал в рассылке вторую нить для обсуждения выживания GCC в долгосрочном периоде. Диего думает, что проект уже мог незаметно пройти точку невозврата и компилятор FSF может умереть естественной смертью.

Выживание GCC в будущем является нашей задачей. Порой я думаю, что мы уже пропустили критический момент.

При этом тот ограниченный круг разработчиков, что может выполнить задачу, как полагается, меньше всего желает её выполнять. Конкретно эти разработчики уже на «ты» с кодовой базой, они приучились выполнять задачи, ради которых были наняты и вместе с другими наёмными работниками сформировали некоторый коллектив. К тому же, освоившиеся разработчики чаще всего отвергают изменения, потому что в ближайшей перспективе они дают нестабильность и ошибки (читайте: головную боль ментейнера).

Эволюционное улучшение кода остаётся неблагодарной и трудной работой. Как инженеру, она мне интересна, но я здраво оцениваю свои силы. В рабочее время мы выполняем другие задачи, которые зачастую по природе своей конфликтуют с эволюционированием кода. Некоторые разработчики уже внесли вклад в улучшение кода в плане названной задачи, но суммарный технический долг кода в GCC огромен.

Если этакие тенденции продолжатся, команда опытных разработчиков GCC со временем начнёт вырождаться. Без обновления этой команды GCC ждёт естественная смерть. Этот процесс начался давно и продолжается сейчас. Ну и кроме этого, будет интересно иметь два или более сильных и конкурирующих друг с другом компиляторов. Обмен наработками (прим. переводчика - в оригинале «перекрёстное опыление», намёк на улучшение генов путём спаривания), к которому ведёт любая конкуренция в opensource, в конечном счёте выгодна всем, и пользователям, и разработчикам.

Richard Guenther отвечал на это

«Учтите, что мы не вправе поставить GCC в гараж и рефакторить его два года. Любая починка ведётся прямо на оживлённой трассе! Это существенно ограничивает доступные нам методики рефакторинга, что в итоге может ограничить и выгоду от их применения. Всегда дважды подумайте, прежде чем превращать GCC в ещё большее болото, чем сейчас!

Есть много других сообщений для тех, кто хочет оценить разные точки зрения от разработчиков и пользователей на тему будущего наиболее популярного свободного компилятора. Вы можете ознакомиться с ними в индексной странице этой нити.

От переводчика:

От себя добавлю, что Erik Verbruggen и я продолжаем работу над интеграцией clang в QtCreator, что в конечном счёте будет полезно всем, кто работает с C, C++ и ObjectiveC. Сегодня с утра я добавил ряд исправлений в механизм автодополнения, а в середине февраля либо параллельно с выходом QtCreator 2.7 добавлю сборки последних стабильных версий QtCreator, clang и плагина для нескольких дистрибутивов: скорее всего это будут Ubuntu (ppa), OpenSUSE (buildservice) и ROSA (ABF). Плагин на порядок улучшает диагностику ошибок прямо в ходе редактирования кода и добавляет неплохое автодополнение (в целом лучше, но в кое-чём хуже встроенного).

Для пользователей арча уже есть qtcreator-clang-git в АУРЕ, но я советую не использовать его, а подождать, пока будет принят мой коммит и пока я отпишу ментейнеру пакета с просьбой обновить его, либо собрать плагин с пылу да с жару по этой инструкции, (по желанию) наложить ещё не принятый патч

git fetch https://codereview.qt-project.org/p/qt-creator/qt-creator refs/changes/23/45923/2 && git checkout FETCH_HEAD
после чего (обязательно) открыть файл clang_installation.pri и закомментировать знаком # строку
DEFINES += CLANG_INDEXING
Это отключит временно неиспользуемое, но сильно замедляющее работу индексирование.

>>> Подробности

★★★★

Проверено: anonymous_incognito ()
Последнее исправление: JB (всего исправлений: 4)

Ответ на: комментарий от anonymous

Некорректная постановка задачи. Нет эквивалентности между qsort и std::sort.

Разумеется, в том то и довод, ряд абстракций выразимых на С++, невыразимы на С. На С можно реализовать аналог std::sort с активным использованием макросов, но контракт такого аналога std::sort будет включать детали его реализации.

Begemoth ★★★★★
()
Ответ на: комментарий от anonymous

Знаешь/незнаешь язык XYZ - это неконструктивная позиция. Если Вас прогнать по стандарту С++ с пристрастием, то, боюсь, отличность Ваших знаний померкнет.

Некорректная постановка задачи. Нет эквивалентности между qsort и std::sort.

Ну вот Вам выше уже ответили про контракт и макросы. Когда я с этими макросами для эмуляции полиморфизма данных на С намучился, я перебрался на С++.

Если знаете, как это сделать без макросов и без элементов реализации метода в его контракте, скажите. Я пополню свою базу знаний.

aist1 ★★★
()
Ответ на: комментарий от sanaris

Дизайн Си++ плохой, как следствие разных пожеланий гигантской соцгруппы его пользователей.

Вы не доказали факт, но повторяете раз за разом. Я надеюсь, многократное повторение фразы не является её доказательством?

Шаблоны пока никому, кроме авторов компиляторов, не мешали. Да и тут претензии скорее к C с его #include вместо импорта, который может появиться в любом месте (препроцессор не смотрит синтаксис) и зависит от состояния препроцессора. Все тормоза clang как библиотеки вызваны инклудом из C, и лишь немного драмы поверх добавляют шаблоны, которые должны располагаться в заголовке.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от quiet_readonly

Про тормоза clang. У меня мой проект активно использует метапрограммирование - много сложных структур данных. Процесс компилятора gcc распухает до почти 2 гигабайт при компиляция с -O3. Примерно до такого же точно объема распухает clang. Причем без оптимизаций ситуация аналогичная - оба компилятора распухают до 1.3 гигабайт. Компилирует clang быстрее gcc процентов на 30 в обоих случаях. clang 3.2 против gcc 4.7.2

aist1 ★★★
()
Ответ на: комментарий от punya

немного офтоп: а разве можно форкать bsd (например 3 clause) в gpl?

Насколько я понимаю, юридических проблем нет. Только моральные и организационные.

Четвертый пункт специально убирали для совместимости.

x86_64 ★★★
()
Ответ на: комментарий от punya

я всегда думал что нельзя, хотя серьезно не проверял

Вот взять часть кода в проект под GPL, насколько я понимаю - нельзя.

Ибо надо будет добавлять дополнительные ограничения, а этого делать нельзя.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

По крайней мере без согласия отсальных, вложивших в проект свой код.

x86_64 ★★★
()
Ответ на: комментарий от aist1

-O3 абсолютно разный cмысл имеют для clang и GCC и ни разу не аргумент. аргумент - бенчмарк времени выполнения самой опримизируемой программы. Как и OPenMP, отладочная инфа (качество ее) и прочее что можно пощупать. Но не циферки в ключах, нет.

anonymous
()
Ответ на: комментарий от hizel

4.2. Не знаещь - промолчи. Полный ЛОР любителей повякать на темы, в которых ни в зуб ногой.

anonymous
()
Ответ на: комментарий от x86_64

Ибо надо будет добавлять дополнительные ограничения, а этого делать нельзя

Почему нельзя?

Даже в glibc есть код под BSD.

unsigned ★★★★
()
Ответ на: комментарий от anonymous

-O3 абсолютно разный cмысл имеют для clang и GCC
...абсолютно разный...

Я так понимаю, что для clang -O3 - это не оптимизация?

С моей точки зрения одинаковый размер кучи процесса компилятора как в режиме -O0, так и в режиме -O3 наводит на мысли о близости внутренних структур данных и алгоритмов обоих компиляторов. Кто-то к кому-то активно поглядывает в код.

aist1 ★★★
()
Ответ на: комментарий от unsigned

Даже в glibc есть код под BSD.

Деталей не знаю.

Возможно изначально нужные условия были. Возможно договорились с авторами включаемого кода. Возможно договорились с авторами остального кода на добавление ограничений.

x86_64 ★★★
()
Ответ на: комментарий от anonymous

свободное время и обязательно поизучаю сорцы git-а.

git clone git://git.kernel.org/pub/scm/git/git.git git tag выбирай любую, там всё гкод

anonymous
()

Ошибки Шланг лучше ГЦЦ распознает ?(

Примерно так gcc.gnu.org/wiki/ClangDiagnosticsComparison ?

anonymous
()

Наглых бсдуной и поклонников Поцеринга тред. Не пройдет! GCC живее всех живых, а все остальное - дань моде.

Sociopsih ★☆
()
Ответ на: комментарий от x86_64

Возможно изначально нужные условия были. Возможно договорились с авторами включаемого кода. Возможно договорились с авторами остального кода на добавление ограничений.

Без всяких «возможно». Код под BSD можно брать и перелицензировать под любой лицензией. Главное, не забыть упомянуть автора этого кода в производном продукте. А вот с GPL такие фокусы не прокатят. То что под ней выпущено, то под ней и останется. Только можно повысить версию, если автор забыл слово only в названии лицензии.

anonymous
()
Ответ на: комментарий от anonymous

Без всяких «возможно». Код под BSD можно брать и перелицензировать под любой лицензией. Главное, не забыть упомянуть автора этого кода в производном продукте. А вот с GPL такие фокусы не прокатят. То что под ней выпущено, то под ней и останется. Только можно повысить версию, если автор забыл слово only в названии лицензии.

Вообще-то там еще два пункта в лицензии BSD.

И ты нарушил правило ОБЯЗОННОСТИ упоминать авторов в производных от тебя продуктах. Кто-нибудь возьмет твой код под простой GPL и выбросит упоминание авторов. Фигня получится. :)

Так что без дополнительных ограничений не обойтись.

x86_64 ★★★
()
Ответ на: комментарий от anonymous

Код под BSD можно брать и перелицензировать под любой лицензией. Главное, не забыть упомянуть автора этого кода в производном продукте.

Именно это и затрудняет перелицензирование кода BSD под GPL. Можно только взять изменнённую GPL с дополнительным ограничением, запрещающим модификацию копирайтов и всех упоминаний первоначального автора.

GPLщики на это частенько кладут, но, думаю, наступит день, когда получат по носу.

Что можно делать не нарушая обе лицензии, так это брать BSDшные файлы целиком и без последующей модификации.

alt-x ★★★★★
()
Ответ на: комментарий от aist1

«Компилирует clang быстрее gcc процентов на 30 в обоих случаях. clang 3.2 против gcc 4.7.2»

Скорость компиляции определенно интересует конечных пользователей. С исполняемым файлом что, где код быстрее ? Можно не отвечать я и так знаю )

anonymous
()
Ответ на: комментарий от anonymous

Ну почему же. У меня сборка длится где-то около минуты. Чем быстрее, тем лучше, когда отлаживаешь код. Clang тут у меня гораздо лучше смотрится в обоих режимах, но не в разы. К моему большому сожалению, clang 3.2 у меня как-то «не очень» работает с отладочной информацией, поэтому gdb в Eclipse CDT пропускает строки.

Мой код быстрее у gcс на 10-15%, но эти данные несколько устарели (gcc 4.6, clang 3.0). Для меня это не принципиально, у меня всё упирается больше в память, чем в процессор.

aist1 ★★★
()
Ответ на: комментарий от x86_64

Возможно договорились с авторами остального кода на добавление ограничений

А что вообще мешает добавлять ограничения? Я перечитал BSDL и не нашёл запрета на это.

К тому же есть вовсе проекты под двойной лицензией.

Другое дело, что убирать ограничения (упоминание авторов) нельзя - ну так я назову их в readme, gpl не запрещает.

unsigned ★★★★
()
Ответ на: комментарий от anonymous

Скорость компиляции определенно интересует конечных пользователей.

Clang спроектирован как платформа для сред разработки и инструментов анализа кода, для которых скорость крайне критична. Какую паузу между вводом . либо -> и появлением подсказки программист готов потерпеть? 50 мс, 500 мс, 3 секунды, 8 секунд?

С исполняемым файлом что, где код быстрее ? Можно не отвечать я и так знаю )

Код быстрее там, где у программиста была возможность его нормально ускорить: в GUI надо любые действия с длительностью более 1/50 секунды делать асинхронными, в числодробилках правильно применить OpenMP и устранить узкие места, в клиент-серверных приложениях нужен гибкий механизм кеширования, при обработке данных (да хотя бы при индексировании кода на сервере тем же clang) надо обеспечить сериализацию и выгрузку данных на диск и т.д.

Где здесь участвует компилятор - я как-то не вижу. То есть, конечно, с -march=native -Ofast -flto эффект будет, но скорее всего вместо ускорнеия будет непереносимая на старые процессоры, а то и поломанная программа (из-за LTO или изменения семантики float/double). На форониксе тестировали Mesa: никакого ускорения, т.к. узкое место не в Месе, а LTO и вовсе поломанный бинарник дал.

И да, на последних тестах фороникса gcc и clang вровень кроме тех тестов, где есть openmp.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 2)
Ответ на: комментарий от unsigned

Другое дело, что убирать ограничения (упоминание авторов) нельзя - ну так я назову их в readme, gpl не запрещает.

Этого не достаточно. Уже писал выше. Необходимо ОБЯЗАТЬ всех кто будет использовать твой проект то же упоминать авторов. А вот это ограничение которое необходимо добавить к GPL. И не во всех проектах это организационно реализуемо.

x86_64 ★★★
()
Ответ на: комментарий от quiet_readonly

Оставим шаблоны на чуток. Вот к вам пришел человек и говорит - хочу по проходу на поле вызов метода. Чтобы так (b.a) -> (b.a) + func(b,a). И вы ему не можете сказать типа «ээй, да вызови вот функцию». Потому что он хочет как в стандарте. А кому там взбрело в комитете? Вон тот же Саттер, известный чел, против целого моря фич голосовал. Комитеты не могут улучшать или фиксить, они только добавляют. Вот проблема.

sanaris
()
Ответ на: комментарий от Deleted

Только вот кто-то их вычитал текущее состояние, и впал в уныние, вместо того, чтобы самостоятельно для C++ предложить решение в виде патча.

Убедил.
Заметить проблему и решить её - золото.
Заметить проблему и предложить решение - серебро.
Заметить проблему и уведомить о ней - бронза.

An12
()
Ответ на: комментарий от x86_64

Этого не достаточно

Все три условия BSDL соблюдены.

Необходимо ОБЯЗАТЬ всех кто будет использовать твой проект то же упоминать авторов

Что ОБЯЗАЛО меня упомянуть авторов? Лицензия, исходники под которой я использовал. Что обяжет других? Та же лицензия, чей текст останется как минимум в исходниках.

http://en.wikipedia.org/wiki/License_compatibility

Many of the most common free software licenses, such as the original MIT/X license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0, and LGPL, are «GPL-compatible». That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole).

unsigned ★★★★
()
Ответ на: комментарий от hizel

Нельзя. Лицензию может менять только автор.

Как бы да, но что, например, мешает сделать форк BSD'шного проекта и лицензировать *свои* изменения под GPL?

sjinks ★★★
()

ему грозит естественная смерть

И как же тогда под iOS кодить?

Bioreactor ★★★★★
()
Ответ на: комментарий от aist1

Знаешь/незнаешь язык XYZ - это неконструктивная позиция. Если Вас прогнать по стандарту С++ с пристрастием, то, боюсь, отличность Ваших знаний померкнет.

И что? Был у меня предподавателем один человек который очень любил чесать свое ЭГО тем что доставал студентов малозначительными мелочами. Вот стоило мне ему показать недалекость его позиции - так он сходу побагровел и потерял не только дар речи, но и самоконтроль. Это намек.

Некорректная постановка задачи. Нет эквивалентности между qsort и std::sort.

Ну вот Вам выше уже ответили про контракт и макросы. Когда я с этими макросами для эмуляции полиморфизма данных на С намучился, я перебрался на С++.

Некорректная постановка задачи

Ну вот Вам выше уже ответили

Как бы ничего не смущает? Все нормально?

Если знаете, как это сделать без макросов и без элементов реализации метода в его контракте, скажите. Я пополню свою базу знаний.

Знаю, но я использую макроподстановку.

anonymous
()
Ответ на: комментарий от hobbit

Component Pascal, но он не популярен.

anonymous
()
Ответ на: комментарий от unsigned

А что вообще мешает добавлять ограничения? Я перечитал BSDL и не нашёл запрета на это.

Никто не запрещает. Можно добавить какие угодно ограничения, в том числе продавать ваше поделие за деньги и запретить распространение его кода. Это BSD и там всё можно.

Vudod ★★★★★
()
Ответ на: комментарий от unsigned

Необходимо ОБЯЗАТЬ всех кто будет использовать твой проект то же упоминать авторов

Что ОБЯЗАЛО меня упомянуть авторов? Лицензия, исходники под которой я использовал. Что обяжет других? Та же лицензия, чей текст останется как минимум в исходниках.

Те, кто будут брать код твоего продукта берут ее по лицензии твоего продукта. Никакие лежащие файлы никакого значения не имеют.

Как тут писали выше. Можно использовать файлы под BSD лицензией. Но если ты взял часть кода, то все. Вариантов нет. Необходимы дополнительные условия.

x86_64 ★★★
()
Ответ на: комментарий от Sociopsih

Вот теперь дискуссия войдет в правильное - широкое русло :) Видел тред на 3-х, а теперь и на 5 страницах... Название все еще «не отражает».

slackwarrior ★★★★★
()
Ответ на: комментарий от sanaris

Ненене, погодите всё складывать в кучу.

Согласен. Но как дальнейшее согласуется с этим благим пожеланием?

Была война Си-Паскаль в массовом программировании, без объектов, в конце 80-х. И это тогда Си считался «более грязным», ибо наконец-то ввёл указатели. То есть этот фактор «расширения возможностей», он тогда сыграл. Си заполнил машинную логику до конца: адреса, инструкции, данные.

Кто на ком стоял, простите? Не было никакой войны: Си как был в энтерпрайзе, так и остался (и указатели он никуда не вводил - они в нем были с самого начала). А Паскалю гадил то маркетинг («„Турбо“ - это несерьезно!»), то... опять маркетинг.

Си заполнил машинную логику до конца: адреса, инструкции, данные.

Что за... В ассемблере не было адресов, инструкций и данных? :) Дальнейшую рениксу про С++ не читал, но осуждаю :)

slackwarrior ★★★★★
()
Ответ на: комментарий от aist1

Я Вас лохом не считаю. Скажите просто, что не будете отвечать.

Инженерное начало во мне за то чтобы опубликовать информацию для анализа, но это идет в разрез с конкурентной реальностью. Но дам подсказку: сама техника несколько выходит за рамки языка.

anonymous
()
Ответ на: комментарий от slackwarrior

А Паскалю гадил то маркетинг («„Турбо“ - это несерьезно!»)

С чего это вдруг? Да и турбо-ц тоже было. Вполне неплохие среды для своего 16-битного времени.

madcore ★★★★★
()
Ответ на: комментарий от anonymous

Инженерное начало во мне за то чтобы опубликовать информацию для анализа, но это идет в разрез с конкурентной реальностью.

Я вот про что. Мы, наверное, друг-друга в начале дискусии недопоняли немного. В результате Вы меня послали изучать исходники перла и ядра. Вот я и подумал, что техника, на которую Вы ссылаетесь, уже не является секретным ноу-хау.

Но дам подсказку: сама техника несколько выходит за рамки языка.

Я не собираюсь извлекать из Вас тайны. Раз уж техника всё же выходит за рамки языка, то предлагаю пока остановиться на моем варианте: обобщенные структуры данных в рамках С не сделать без потери эффективности, не привлекая при этом кодогенерацию сторонними средствами (макросы?).

Другое дело, что такая потеря эффективности на практике может быть незначительной. Поэтому спор не стоит нервов.

aist1 ★★★
()
Ответ на: комментарий от aist1

не привлекая при этом кодогенерацию сторонними средствами (макросы?).

Что-то я не видел крупных проектов не только на C, но и на C++, где не использовались бы макросы в большом количестве. Если вы считаете, что Си без макросов --- это настоящий Си, то тогда для вас плохие новости: он малопригоден в современных реальностях.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Если вы считаете, что Си без макросов --- это настоящий Си, то тогда для вас плохие новости: он малопригоден в современных реальностях.

Весь этот тред --- это какая-то изба-непонимальня :)

Нет, я так не считаю. Я считаю, что С++ --- это блэкджек и шлюхи. Поэтому я на нем программирую для души. А для работы у меня есть языки попроще.

aist1 ★★★
()

Я как имеющий отношение к GCC, скажу вот что. Я не понимаю смысла дискуссии о будущем GCC. Без GCC просто не будет ничего. Ни пакетов к убунтам, ни сборок GIMP для Windows. Никакое LLVM или любой другой конпелятор не поможет, «если вдруг» GCC исчезнет. Замучаетесь просто.

mr_doug
()
Ответ на: комментарий от mr_doug

Я не понимаю смысла дискуссии о будущем GCC. Без GCC просто не будет ничего.

Взамоисключающие параграфы, разве нет? Дискуссия потому и состоялась, что часть разработчиков GCC заметила некоторые пятнышки в светлом будущем.

quiet_readonly ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.