Про лицензию — это не совсем так. Gcc к каждому приложению линкует libgcc/libstdc++, которые тоже под GPL, но с «исключением линковки». Смотри пояснение «Почему данные в промежуточном представлении компилятора исключены из определения “целевого кода”?».

Там написано (перефразируя), что если ты достаешь промежуточные представления компилятора и как-то это используешь в своем не-gpl-ном коде, то результирующий код (не важно как и чем потом полученный) у тебя будет под GPL.

Во время разработки — кланг, потому что мак. В прод гцц собирает.

Не голосовал, т.к. устраивают оба.

Ну c++17 фичи) я б попробовал clang его собрать, но пока что времени свободного мало

ctags + комплит по токенам (хз как где, а в виме дефолтно идёт) + всякое типо grep и sed - это всё, что на самом деле нужно. Перейдя на такой набор заметил, что особо ничего не потерял, даже наоборот - избавился от этого жутко тормозного и падучего монстра. Это даже плюс для ГЦЦ, что он не ввязался во всю эту хипстерскую докомпиляцию и соответсвующие инструменты (аналоги libclang, лсп сервер) оставив себя проще. Вот если он научится быть дружелюбным для желающих вкручивать в него плагины, то цены ему не будет.

Самое странное, что перед включением в llvm их эти фичи просили убрать, емнип.

Собрать не получилось пока - один поток время от времени хочет аж 5 Гб, а у меня всего 4 и дальше лезет в swap. И то не факт, что сборка дальше не сдохнет, а бинарной сборки среди тарболов релиза пока не видать, но, кажется, были среди release candidates.

И то моя заготовка для ebuild пока пытается без учёта multilib собирать, поэтому я даж пока не знаю, что на выходе и пытался ли он mlir подцепить, который отдельно собран (правильно ли собран?).

Хотя формально flang можно найти в поставках от pgi sdk (от nvidia), aocc (от amd). Можно у intel выпросить ещё попытаться.

Не понял, пример чего это?

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

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

Хрестоматийный пример — это закрытый проприетарный оптимизатор перед кодогенерацией (экзотическое железо, например). Или даже сам кодогенератор. Т.е. на основе GCC нельзя сделать C/C++-фронтенд для своего собственного тулчейна. Точнее, можно, но без libgcc/libstdc++ (и еще кучи всяких crt-файлов).

Из-за этих подводных камней лицензирования, Apple прекратила использование gcc, начиная с какой-то версии. Потому что ты не можешь легально комбинировать gcc со своим проприетарным кодом. Если ты это сделаешь, то твои выходные файлы будут под GPL.

Вроде бы gcc компилирует более быстрый байт код, чем clang. А ещё при использовании шланга, некоторые программы при сборки выдают ошибки, потому что версия языка почему-то не переключилась, а в gcc все нормально.

Какую плодоносную поляну? Ты рассуждаешь коммерческо-проприетарными шаблонами.

В задачи проекта gcc не входит битва за клиентов. В задачи проекта gcc входит создание хорошего компилятора. Для тех, кому нужен хороший компилятор. Незачем никого туда заманивать или заставлять, не хотите - не пользуйтесь.

И что за часики?

Потому что моё точно собирается gcc и робит. Ставить эксперименты ради экспериментов, скучно же.

Ну да, не выпиливали, его там никогда по дефолту не было в мэйнстримных дистрах.

Ви таки что-то хотели сказать не за Патрика?

Turbo C

Ничего себе, его оказывается даже бесплатно раздают.

Верите, нет, моим пользакам побарабану, они и слов таких не знают.

Изнутри шланг куда менее наркоманский, но хз, гцц привычнее

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

Креветка же.

При прочих равных я предпочту не использовать C.

Всмысле?

его там никогда по дефолту не было

Проголосовал в поддержку меньшинств (clang)

Понял. Благодарю.

А можно одним предложением всё сказать? Намёки эти я не понял совсем.

В слаке он есть. И давно.

Площадку инструментов для С/C++. Если ты в курсе, как обстоят дела в Java и других современных языках, то инструменты для C++ застыли где-то в 80-х. Продуктивность работы с кодом С++ программиста гораздо ниже программиста на Java там, где используется инструментирование. В третьей декаде 21-го века принято всё, что можно автоматизировать — автоматизировать («<xyz> as a code»). Как мне произвольную не-POD структурку в поток записать без танцев с бубном в виде ручного написания кода?

Если ты думаешь, что всё это «не нужно», то ты просто в пузыре. Этого нет, ты об этом не знаешь, никто об этом не знает, поэтому оно и не нужно. А между тем, С и С++ не являются языками программирования «в большом». Первый даже пространств имен не имеет, а в последнем нет поддержки модулей. Нет даже пакетного менеджера, который бы эту поддержку модулей осуществлял.

Так вот, если ты понимаешь, что твоему проекту необходимо инструментирование, то делать ты его будешь с помощью clang. Там дофига уже готовых инструментов.

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

А тем временем, когда люди стали просить Столлмана добавить автокомплит на основе AST в Emacs для C/C++, тот заартачился и сказал «нет». Всё вокруг свободное и открытое, но это создавало бы прецедент типа, «ребята, мы открываемся». Он был согласен экспортировать лишь какой-то самый минимум информации из AST.

clang. Не засирает память при компиляции, в отличие от.

А ядро уже давно надо разрабатывать так, чтобы оно любым компилятором собиралось, даже MSVC.

У тебя как-то всё в кучу смешалось. Чтобы сделать автокомплит (единственное, что ты из полезного упомянул) - не нужно ни разрешение Столлмана, ни gcc вообще. Парсер синтаксиса это очень простая штука, которая наверно занимает меньше 0.1% кода gcc и вообще пишется в одиночку с нуля за небольшое время.

Касательно остального

без танцев с бубном в виде ручного написания кода

эта фраза всё о тебе говорит. Если для тебя написание кода это танцы с бубном, то не надо строить из себя программиста и выдавать «экспертное» мнение.

делать ты его будешь с помощью clang

Просто нет.

единственное, что ты из полезного упомянул

Я же сказал, что ты в пузыре. Если ты не считаешь, что там есть что-то полезное, то это не значит, что его там нет. У других людей другие задачи — другие потребности.

Если для тебя написание кода это танцы с бубном, то не надо строить из себя программиста и выдавать «экспертное» мнение.

Я программист, а не кодер. Я получаю зарплату за функционал, а не за строчки кода. Да, я не собираюсь вручную писать то, что во всех других случаях уже программы пишут сами.

Просто нет.

Просто делай, как хочешь. Посылаю тебе светлые лучи искренней поддержки. GCC в плане тулинга и модульности от clang сильно отстает, нужно как-то нагонять разрыв. Или не нужно. Дело твоё.

4.2

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

У нас кодген на кастомном атрибуте работает.

12-я версия? Ок, я проверю. Хорошо, если так. Я сейчас через clang::annotation() пробрасываю.

Когда gcc перестанет собирать Chromium целый день?

Не занимаюсь сборкой хромиума и вам не советую.

Clang, потому что инструментов для отладки, диагностики и помощи при компиляции значительно больше.

https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2

GCC 12 Enables Auto-Vectorization For -O2 Optimization Level

Как вы там, рисеры?

А ядро уже давно надо разрабатывать так, чтобы оно любым компилятором собиралось, даже MSVC.

Но зачем? Без GNU Linux не нужен. А если появится вдруг альтернативный набор софта, типа как у BSD, напишут скорее всего и свое ядро.

Ты хотел сказать, без костылей GNU и его нестандартных расширений Linux не нужен?

Ну да, это и сказал.

Linux - gcc, MacOS - clang. Без каких-то определенных мыслей, просто что есть по умолчанию.

gcc
clang пока что местами нестабилен при использовании оптимизаций. Как сам может падать при компиляции, так и сгенерированный им код иногда ломается оптимизатором

У меня на практике получилось, что gcc лучше чем clang векторизирует циклы (использовались вычисления fp32, с опцией fast-math).

Т.е. плагины сделаны преимущественно для анализаторов кода, а не для расширения возможностей компилятора.

https://github.com/mshockwave/nacro ?

Годнота! Благодарю!

Ок. Они через pragma пробрасывают текст в плагин, где он «дообрабатыватся». Я изучу их техники, пригояится :)

Мне самому больше нравится вот этот форк: https://github.com/lock3/meta

Полноценные процедурные макросы там делать нельзя, но сам квотинг всё же есть. И это имеет шансы войти в стандарт в будущем, так как специально для этого и делается.

Т.е. плагины сделаны преимущественно для анализаторов кода, а не для расширения возможностей компилятора

См. например https://github.com/woboq/moc-ng

Тоже годно. Но это все не о том, о чем я говорил.

Плагины в clang, их API, не сдизайнен для модификации AST. И если ты всё же делаешь модицикацию AST, то надо смотреть, как это воспримет CodeGen. Т.е. это сильно текущая абстракция.

Плагины, которые делают аналитику кода, или которые просто создают дополнительный код, помещаемый в другие TU, будут работать отлично. Тут проблем нет. Разве что если хочется расширить язык, добавив, например, какой-нибудь свой оператор, то сам парсер — не модульный. И плагинами не расширяется. Тут надо будет делать форк.

В форке, самом по себе, ничего страшного нет. У меня, например, свой форк есть. Если собственный код хорошо отделен от апстрима, то периодически накатывать апстрим поверху проблем не составляет.

Даже распространять форк тоже проблем особых нет. Его можно распространять, например, как собственный бранч в Vcpkg.

Что касается самих плагинов, то их использовать не обязательно. clang достаточно модульный для того, чтобы использовать просто один его фронтенд в виде библиотеки. Это дает сильно большую гибкость в плане конфигурирования. У меня так в Мемории Codegen работает. Это интегрированный с Cmake экзешник, который дергает парсер, имеет объектную модель ресурсов проекта на С++ и, собственно, темплейтинг на Python (jinja).

Разве что если хочется расширить язык, добавив, например, какой-нибудь свой оператор, то сам парсер — не модульный.

Чтобы сделать его модульным, пришлось бы пожертвовать скоростью, а на ранних стадиях развития проекта это был основной selling point. Да и вообще, такие радикальные изменения языка интересны довольно небольшой категории граждан, по сравнению с анализом AST и генерацией дополнительного кода

Я же не спорю. Они всё делают просто замечательно. Причем в плане модульности оно становится только лучше. Не так быстро, как хотелось бы, но все же «небо и земля» по сравнению с альтернативой:

By forbidding the editor from having advanced knowledge of the parse tree, you are intentionally crippling the ability of smart people to build better and better free software tools. You are preventing smart hackers from going in and making the system as good as they can make it, from expressing their creativity in such a way as to build the best development environment they know how.

В clang продвинутые инструменты для умных людей поощряются, и сообщество для этого делает все возможное в рамках разумного. В gcc же, наоборот, стараются твою жизнь затруднить. А то, слишком умные, понимаешь. Не все и не всегда, разумеется. Но ты всегда вынужден будешь продираться через «кордоны охранителей», если захочешь донести альтернативную позицию.

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

В линуксах обычно вообще нет такого понятия как базовая система

ВНЕЗАПНО есть

Оба. Проект должен собираться что одним, что другим

1. Gcc для всего по-умолчанию. Всякий эмбеддед может в Gcc, но не в Clang. Для того, с чем работал: X-Tensa (ESP32), MicroBlaze (Xilinx Soft Core).
2. Clang косвенно в Qt Creator для Codemodel (исключения выше портят жизнь), плюс всякие clang-format, cland-tidy.

Для сборки Gcc больше по привычке использую. Приниципиальных причин отказываться не вижу.