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)

Я думаю что лучше не переделывать. У GCC наверняка есть области где он полезен как есть. Несколько путей лучше чем один.

Xenius ★★★★★
()

Скандалы, интриги, расследования!
Онолитег из проприетарной компании похоронил свободный компилятор!
Шок! Видео! Скачать без смс!

p.s. Моська тявкает, а караван идет.

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

Читай удаленные или пройди уже по ссылке.

А в чем противоречие, я что-то не понял? Я разве не сказал *то же самое*? И почему мне вдруг должно прийти в голову читать удаленные к этому треду? Все верно я написал. :)

Zubok ★★★★★
()

GCC уже прошёл точку невозврата и ему грозит естественная смерть.

Собственно, как и Linux. Bloated and huge.

anonymous
()

К сожалению, связка LLVM и Clang выглядит более перспективной. Легче быстро развить новый проект с правильной архитектурой, чем ковырять написанное кто знает когда ПО, в котором боязно что-то трогать(потому, что велика вероятность регрессий). Как говорил Линус в книге just for fun, когда-то и Linux сменит более совершенное ядро...

lucentcode ★★★★★
()

очень интересно

неужели все так запущено ?

kto_tama ★★★★★
()

Посоветуйте хороший мануал по clang (и llvm), а то на сайте у них очень смешной.

anonymous
()

Компилятор то уже на плюсах или как?

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

не надо забывать, что gcc распространяется под gpl, а clang/llvm — проприетарщина бсдшная, поэтому свёртывание gcc очень больно ударит по спо в целом.

Разве лицензия BSD не позволяет сделать форк под GPL?

Bagrov ★★★★★
()

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

Evtomax
()

LLVM/Clang пока ещё явно не дотягивает до GCC в плане подержки C++ и в плане оптимизации кода (на phoronix.com недавно тесты были).

Clang может и станет лучше но ему надо для этого явно ещё несколько лет. Ну и не забываем про то что gcc на месте не стоит и 4.8 скоро войдёт в жизнь.

Не факт, что всё это является недостатком g++.

Ну да, gcc это хорошая система для компиляции но не для встраивания всего и во всё. Лично я его использую именно для компиляции.

stalkerg ★★★★★
()

Кстати, clang можно заставить банальным образом ругаться на отсутствие \n в конце c-файла, как это делал gcc <=4.2? Или надо фронтенд свой делать?

А то в связи с разрешением на отсутствие \n в конце файлов на c++ из gcc убрали мой любимый ворнинг.

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

Или надо фронтенд свой делать?

Там оно уже есть:

def ext_no_newline_eof : Extension<"no newline at end of file">, 
  InGroup<DiagGroup<"newline-eof">>;
def warn_cxx98_compat_no_newline_eof : Warning<
  "C++98 requires newline at end of file">,
  InGroup<CXX98CompatPedantic>, DefaultIgnore;
anonymous
()
Ответ на: комментарий от stalkerg

LLVM/Clang пока ещё явно не дотягивает до GCC в плане подержки C++ и в плане оптимизации кода (на phoronix.com недавно тесты были).

Ты ничего не путаешь? «явно не дотягивает до GCC в плане подержки C++» — это уже давно не так.

http://www.phoronix.com/scan.php?page=article&item=llvm_clang32_final

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

Там оно уже есть:

А, спасибо, в моем старье значит нет...

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

А пример этих компиляторов можно, имеется в виду проектов, которые вышли во что-нибудь дельное, а не YetAnotherSuperStudentCompiler

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

Так они же наколенные и сдаются как курсовая, зачем им во что-то дельное. Если же говорить о дельных областях применения LLVM, то ЕМНИП это один из бекендов для хаскелльного GHC и различные компиляторы шейдеров (в mesa), CUDA (от nvidia) и OpenCL (sdk от amd).

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

Спасибо за перевод актуальной, интересной статьи.

Последнее исправление: Cypher 27.01.2013 23:16:13 (всего исправлений: 3)

всего исправлений: 3

OMG.

anonymous
()

1) От компилятора нужна оптимизация. (Вдумайтесь в само слово - компилятор, не транслятор же.) Поэтому компиляторы создаются для хороших (как Си и Ф77-Ф90), языков. Плохие языки, как всякие там плюсы, рубины, змейки и шарпы, изнутри, по сути, переводчики на хорошие языки. Может быть какие-то простые нормализации делаются, чтобы было поменьше оверхеда, но не более.

2) Я ненавижу инфляцию хороших продуктов. ГЦЦ превратили просто в свалку языковых шлаков. Это (а) раздувает объём, (б) затрудняет навигацию.

Вывод: кастрировать всякое уродство, выжечь напалмом, раздавить гадину. Пусть все левые языки тусуются в отдельных ветках и проектах. Столлману не хватает жесткости как Линусу.

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

Не, ну давайте не будем, давайте уже какую-нибудь реальную задачу. Погоду там посчитать, или KHI. Я, как и один автор тестов Химено - предлагаю линейный сольвер какого-нибудь уравнения, Лапласа того же. Когда я последний раз проверял языки, после ГЦЦ шёл вовсе не Чланг, а ПГФ.

sanaris
()

C++11

Ē-моē! Не успеешь начать ненавидеть "плюсы", как еще подвид какой-то появляется!

GCC — отличнейший компилятор! Чего народу надо?

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

Ē-моē! Не успеешь начать ненавидеть «плюсы», как еще подвид какой-то появляется!

man C99, C11 и т.п.

GCC — отличнейший компилятор! Чего народу надо?

кому-то высокая скорость компиляции, кому-то лучший показ ошибок и статический анализатор, кому-то интеграция в свое IDE/редактор, кому-то простое создание своего фронтэнда под свой ЯП или бэкэнда под платформу, даже в таком виде: https://github.com/kripken/emscripten/wiki, и т.д.

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

man C99

Пользую часть "фишек". Удобно. Но не все.

высокая скорость компиляции

Он же поддерживает многопоточность.

лучший показ ошибок

Куда уж лучше?

статический анализатор

[штоэта?]

интеграция в свое IDE/редактор

vim, emacs, geany… Интегрировано, работает. Только все равно в командной строке make запускать приятнее.

простое создание своего фронтэнда

И каким боком здесь компилятор?

под свой ЯП

тем паче gcc?

https://github.com/kripken/emscripten/wiki

а тут-то gcc при чем?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от unfo

Интелевцы божились, что они GCC'шникам SILK (референсную реализацию) проталкивают. Могу у местных спросить, как оно проталкивается.

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

Он же поддерживает многопоточность.

ему есть куда расти, т.к. он проигрывает однопоточным реализациям:

http://bellard.org/tcc/#speed

ну и clang

Куда уж лучше?

http://clang.llvm.org/diagnostics.html

[штоэта?]

http://clang-analyzer.llvm.org/

vim, emacs, geany… Интегрировано, работает.

для рефакторинга, автокомплита и пр.

И каким боком здесь компилятор?
тем паче gcc?

«The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go» - таким же, только под llvm фронтэнды пишутся меньшими усилиями

а тут-то gcc при чем?

таким, что человек взял и прикрутил нужный выхлоп, кому-то надо выхлоп в байткод .NET, код под редкую «железную» архитектуру и пр. - с llvm легко можно написать бэкэнд, без правки самого компилятора

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

А разве что-то, кроме лени и недостатка компетенции, мешает Вам взять тот же GCC и исправить все его недочёты?

Тут проблема не с лицензией как таковой, а с теми, кто определяет, куда это всё поедет. Пока это был FSF (ну, ладно, пока считалось, что это FSF), у сообщества СПО было ощущение, что мировое господство - не за горами. Ну или, по крайней мере, достижимо. Когда это стал Эппл, ну, только самые конченные бздуны могут думать, что они что-то решают.

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

AlexM ★★★★★
()

Мда помочь gcc конечно хочется, но уровень мой не тот :(. Даже страшно посмотреть какое месиво там у него внутри.

Dron ★★★★★
()

по моему точка невозврата таки была в прошлом году.. хочу вас обрадовать немного GCC ещё есть в 2015

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

«Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.»

Написать рядом свои сурсы под GPL конечно никто не мешает.

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

Если говорить про хорошие языки, то всё хорошо. Все компиляторы делают одно и то же, т.е. проброс в формы SSA (не знаю есть ли русский аналог), затем раскрутка циклов - анализ зависимости переменных, анализ потока исполнения. В этом пространстве, «поток исполнения - переменные», решается задача компилятора по уменьшению условного времени работы алгоритма, для ЗАДАННОЙ архитектуры ( хээээй фанаты ЛЛВМ - вы какой архитектуры придерживаетесь??:) ). Есть к примеру архитектура итаниум - где ллвм для итаниума??

ЛЛВМ в принципе мертворожденная идея, потому что у компилятора нет бэкэнда, бэкэнд компилятора есть машина.

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

ЛЛВМ в принципе мертворожденная идея, потому что у компилятора нет бэкэнда, бэкэнд компилятора есть машина

Эта мертворождённая идея даёт результаты на одном уровне с GCC без флага -fopenmp.

И я не понял что значит «бэкэнд компилятора есть машина». ckotinko хоть на что-то понятное ругался: на потерю метаинформации при преобразовании кода в IR и отсутствие обработки известных ошибок в чипах.

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

Структура ЛЛВМ: (x86, arm, etc)(LLVM)(Clang) Это есть хорошо, когда хочется поиграться, придумывая новый процессор. Но де-факто вы компилируете не с первой на нулевую платформу, а с второй на первую. Так что забыть про реальные проекты. Еще одного уровня до машины нам так и не хватало. Понятно, что всё равно какую-то промежуточную архитектуру компиляторы поддерживают между таргетами, но исключительно ради простоты устройства самого компилятора.

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

Эта мертворождённая идея даёт результаты на одном уровне с GCC без флага -fopenmp.

Вещам, которым, действительно нужен openmp, Риппер Джон и СмаллПТ, сходи по ссылке изена с CTRL+F «openmp».

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

clang/llvm - это хорошо, но кодогенератор например для х86 сливает начисто gcc.

совсем недавно я обнаружил обратное на ARM кодогенераторе, в целом, гцц прилично отставал от шланга. При этом, llvm генерил более «умный» листинг. Ну после этого я обеспечил своим проектам сборку и тем и тем. Печально слышать про гцц такое, я думал он бурно развивается, а тут такое...

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