Debian: clang способен заменить gcc

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

Толсто.

Действительно толсто.

Вообще, я лелею утопическую мечту, что сишечка когда-нибудь умрет, освободив место для паскалеподобных языков :)

Неосилятор?

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

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

Хотя пусть и те и другие будут.

для фортарана есть f2c, паскаль не нужен

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

Пришел ресет и всех жизни научил. Сам не любитель паскаля, но экстремистов терпеть-нинавижу.

Я действительно не осиливаю понять, зачем сишечку тащат в юзерспейс :)

Посоны, я тут в генте поставил этот шланг, glibc им не желает собираться, что делать?

паскалеподобные с непонятными ограничениями

Какими ограничениями?

Я выше уже писал, что С — идеальный язык для низкоуровневых частей ОС, но писать на нем пользовательские программы — идиотизм.

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

А как там в Обероне с обобщенными(параметрическими) типами?

(Читать вкладку GCC-LLVM Comparison, там и графики и всё остальное)

Графики не актуальны, т.к. используется 2.9 вместо 3.0. При этом «December 1, 2011: LLVM 3.0 is now available for download!».

вместо того чтобы осилить pimpl - молодец, чо

Точно, кто не знает о forward declaration тот пол дня ждет сборку проекта.

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

Ну да, а разрабы и не знают - «An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore.»

An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore

И на какой из этих архитектур LLVM является основным компилятором в какой-нибудь системе?

кто ж так вбрасывает? нужно было упомянуть gccGo

Будет быстрее - станет дефолтным

open64 быстрее уже сегодня

clang штука конечно перспективная, но пока сильно сливает на ARM платформе, к тому же ещё и багов наплодило к «счастью» для iOS-деволоперов(жалко потерял где-то линки на попоболь некоторых разработчиков)...

Использую именно llvm для сборки под ios - никаких проблем по сравнению с gcc не наблюдаю.
В основном весь код на c++, с редкими кусками платфоромозависимого кода на obj-c.

вообще в шоке от того, что Apple долбанулась и это чудо в Xcode by default завернула.

Ну тут не llvm виноват, а тормозной и глюкавый xcode. Не нужно использовать в качестве отладчика llvm - xcode 4.2 стабильно падает. С gdb таких проблем нет. Но парсить вывод отладчика xcode толком не умеет.

время сборки стало критично

gnetoo же

костыли для конпеляльщиков не нужны, носите либы с собой

два, нет три чая этому господину!!!

вот и дошколята подтянулись

После перехода Xcode на llvm я нашел два очень редко появляющихся бага компилятора.

Хочу подробностей. Кроме багов xcode я пока ничего не наблюдаю. Спасает, что xcode используется как сборщик ipa и отладчик. Для остального macvim.

всё правильно: пока не потыкал палочкой полез в код — не завоняло

И на какой из этих архитектур LLVM является основным компилятором в какой-нибудь системе?

Речь была о том, что llvm не поддерживает ничего кроме x86. Я показал, что это не так. А где он там дефольтный, меня не волнует.

И на какой из этих архитектур LLVM является основным компилятором в какой-нибудь системе?

На первых четырех. Но речь шла об опровержении 4.2 «поддержки генерации не-x86 кода в clang и llvm не наблюдается» и «одноархитектурное это всё».

Речь была о том, что llvm не поддерживает ничего кроме x86.

Речь была о том, что «нет вменяемой кодогенерации». «Retargettable code generator» есть в любом современном компиляторе, вопрос в его качестве («вменяемости»).

На первых четырех

Вру, на пяти.

currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC

И на какой из этих архитектур LLVM является основным компилятором в какой-нибудь системе?

На первых четырех

PowerPC64? Это какая ОС?

glibc им не желает собираться

выкинуть glibc

Смотрим первые строчки таблицы «list of errors»
1) The most common issue is about the the inline behavior. clang is following by default the C99 standard while gcc promote GNU89.

И? Разные стандарты по умолчанию включены, как здесь прямо и написано. Это говорит о том что gcc неправильно поддерживает стандарт или что?

2) An other issue is that gcc is that gcc optimizes the call to some functions at -O0 (causing -lm to be not necessary)

А это по-твоему говорит о проблеме в gcc что ли? Ну забыл кто-то -lm прописать при сборке и всё. Это не проблема gcc в любом случае.

This problem is that g++ accepts code which should be refused.

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

Дык я тоже не писал на С ничего кроме подписывальщиков да архиваторов. Для пользовательских программ С++ наше фсе. А если что по-быстрому залабать да забыть - питон.

пусть фиксят фейлы 1381 пакета, тогда и предлогают... А пока рассаво верный gcc годен

Какими ограничениями?

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

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

Но это мое ИМХО, начинал на фокале и ПЛ/1, потом паскаль, потом С, как познакомился с С++, грустно стало смотреть на жабу. Нравится пистон идеей заставить писать структурированные программы и практически полной поддержкой ООПа, как это есть в С++. Не нравится руби, потому как в основе лежат бредовые, незаконченные идеи.

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

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

Ну и насколько там хорош C++ в плане компиляции существующего кода? Это не троллинг, я действительно не имел сомнительного удовольствия разрабатывать что-то для мака.

А как быть с x86? «Нипайдет» ©

*GCC - это целая среда с бэкендами*

Точнее набор фронтэндов с бекендом.

Ну clang — это front-end к llvm. Для llvm этих фронтэндов писано не меньше, чем имеется в gcc (в том числе и gcc, кстати, — вариант айфона, кажется). Ну нет ады, зато есть ocaml и haskell... И непонятно что лучше :)

Да как-то real(16) пока хватает :)

Только как компилятор C. Просто не надо забывать, сто clang - это всего лишь компилятор и не более того. GCC - это целая среда с бэкендами. Коллекция компиляторов. Для GCC можно написать бэкенд. Для Clang - фигушки, так как это только компилятор.

Для llvm можно написать бекенд и фронтенд(и, кстате, гораздо проще чем для GCC). А для вот для g++ как раз фигушки! :)

И на какой из этих архитектур LLVM является основным компилятором в какой-нибудь системе?

Очень скоро станет как минимум на i386/AMD64 и, возможно MIPS

Использую именно llvm для сборки под ios - никаких проблем по сравнению с gcc не наблюдаю.

В сети при решении своей проблемы натыкался на траблу, когда у людей начиналась феерия со структурами(то ли простейший CGPoint, то ли ещё чего) в некоторых ситуациях, но багу пофиксили официально. Ещё не раз видел сетование на ARMv6. Что забавно, Apple его поддержку на днях выпилила, теперь для аппрува проекта сборка должна работать под ARMv7 only.

я лелею утопическую мечту, что сишечка когда-нибудь умрет, освободив место для паскалеподобных языков :)

Действительно, утопическую, ибо пока происходит наоборот.

По теме - новость хороша для разработчиков и гентушников, понятие «дефолтный компилятор» в бинарном дистре вообще не критично. Но релизы все равно будут выкатывать с gcc.

В какой ОС?

Ты стандарт Fortran77 видел? Покажи хоть одну программу написанную на нем, без extensions.

В какой ОС?

FreeBSD. Сейчас уже в базовой системе. Просто не включен пока по дефолту.

pgf слабо пригоден для mixed language projects, даже если не учитывать что все окружение собирается gcc.

Gcc куда стабильней

gcc имеет 15 лет форы хождения по граблям и исправления не менее интересных багов

Не знаю никого кто бы писал на фортране новый код. Максимум что используется это legacy код на f77.

Есть много кода на f99

Я какая версия Фортрана используется?

для legacy пусть остаётся gcc

FreeBSD настолько уверенно чувствует себя на MIPS, что собирается перейти на LLVM там? Почему не на ARM - второй по отработанности платформе для LLVM?

множественное наследование

Мой мозг, оно только в CLOS смотрится вменяемо.

генерик

Это да, но вот в Аде они давно есть, в FPC и Модуле-3 тоже. Во второй Модуле, емнип, есть расширение. Как насчет Blackbox'ов всяких — не помню.

конструкторы по умолчанию, переопределение операций

Не помню, что с ними, но в FPC вроде были.

функции с переменным числом параметров

В С они очень криво реализованы. Нет _стандартного_ и переносимого способа сгенерировать список аргументов на лету. Я с ними намучался при написании оберток.

ООП ... C++

Только yoghurt'у не говорите.