А в чем прикол clang?

По поводу уместности модульного подхода, можно еще вспомить монолитный Linux и модульный GNU Hurd. Где сейчас Linux и где GNU Hurd?

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

В идеальном мире так и было бы. В мире C, где стандарт написан непонятно каким органом, получается немного херота. И ведь непонятно, кто прав в итоге, потому что в стандарте какая-нибудь отписка типа implementation defined.

Это опять-таки спорно.

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

можно еще вспомить монолитный Linux и модульный GNU Hurd.

Можно ещё вспомнить Windows, в котором дрова активно в юзерспейс выносят. Где сейчас Linux и где Windows?

Нормальная архитектура.

Это эмпирический опыт из индустрии.

Этот опыт неоднозначен.

Модульность подразумевает наличие некоего API для стыковки модулей, которое должно не сильно часто меняться. Это может создавать дополнительные сложности, если требуется как-нибудь расширить функционал. Это может замедлять работу программы, потому что надо заниматься какой-то там сериализацией-десериализацией, чтоб вот по такому-то конкретному API передавать что-то из одного модуля в другой.

Не факт, что конкретно применительно к компиляторам, модульность лучше монолитов. Если мы хотим не только компилятор, но и еще какую-то НЕХ, которую можно прицеплять к IDE - модульность тут конечно полезней не-модульности.

Можно ещё вспомнить Windows, в котором дрова активно в юзерспейс выносят.

Модульность в GNU Hurd и модульность в винде это просто небо и земля.

Я и под Linux могу дрова в юзерспейс вынести, сделав это через какие-то ioctl

А, ну такое-то-ж норма для сей. Я думал, там баг какой видно.

В идеальном мире так и было бы. В мире C, где стандарт написан непонятно каким органом, получается немного херота.

Это не только в мире C, но вообще в нашем мире. Взять те же стандарты мира Web-разработки, например.

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

Почему тогда всякие мелкие проекты выбирают gcc, а не clang?

Например:

1. для KolibriOS есть gcc 5.4.0, а LLVM нет.

2. Для Windows XP есть gcc 9.2, а LLVM остался лишь версии 3.7

3. Для OS/2 есть gcc 9.2, а LLVM нет.

Если у LLVM всё модульно и легко, а gcc это боль и страдания, тогда почему архитектур и платформ больше у gcc?

Возможно, на момент когда этим платформам захотелось компилятор, llvm ещё не было или он был совсем сырой. А потом просто уже проще было тянуть дальше gcc, а не переписывать всё.

Потому что GCC проще в применении, чем LLVM.

для KolibriOS

Для Windows XP

Для OS/2

Хахахахахаха! Это, кстати, можно объяснить некрофилией. GCC потихоньку дохнет из-за ненужности, и некрофилы его только больше начинают любить.

Проблема в том, что GCC не соблюдает принципы UNIX-Way, он монолитен.

(вспоминает про ненужнод и ворчит) Кого это нынче колыхает…

Но тем не менее gcc монолитен

нет

и добавление туда нового языка или архитектуры очень большая боль

нет, но и мануалов нет, а у clang они есть

GCC не соблюдает принципы UNIX-Way, он монолитен

и в чём же заключается его монолитность?

В треде уже всё разжёвано (не только мной), Clang/LLVM как никрути получился куда более UNIX-Way’ным.

а картинки похожи

https://www.researchgate.net/figure/GCC-Architecture_fig3_307545338

https://habr.com/ru/post/459704/

прочитал весь, никакого «разжёвано» не нашёл