Пока всё равно функциональных полноценных открытых альтернатив gcc нет. CLang достаточно сырой и с неправославной лицензией.

but initial results seem to indicate a 6% slowdown on Mac and a 16% slowdown on Linux.

Гыцыцыкапец откладывается?

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

да gcc-измы испраивли и все.

а что это он под маком так хорошо собирает, в отличае от лялиха. Видать статический анализ на obj-c коде работает

а. разные версии gcc

> but initial results seem to indicate a 6% slowdown on Mac and a 16% slowdown on Linux.

Мне больше понравилось про рост отладочного бинарника на 117%.

Совсем недавно говорили, что там вообще с с++ плохо было.
А насчет gcc-измов, не думаю, что они были в Qt, поскольку оно нормально компилится msvc и icc.

> Пока всё равно функциональных полноценных открытых альтернатив gcc нет. CLang достаточно сырой и с неправославной лицензией.

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

патенты не нужны. и будем надеяться что ябл защитит шланг

> патенты не нужны

Однако из-за них отказались от gif, арифметического сжатия, и еще множества других интересных вещей. Когда обладатель патента попросит у тебя денег за то, что ты посредством llvm используешь его интеллектуальеную собственность, вот тогда и будешь товарищу прокурору рассказывать а ненужности патентов.

и будем надеяться что ябл защитит шланг

Посмотри, как MS своими патентами берет со всех денег за линукс. Ни ИБМ, ни Оракл в разборки не вмешиваются. Вот и яббл точно так же вмешиваться не будет. Зачем ему?

гном тоже собирается

Голос из танка:

<голос_из_танка>
А чего все с этим clang так носятся? Что в нём такого особенного?
</голос_из_танка>

> А чего все с этим clang так носятся? Что в нём такого особенного?

1. llvm - очень интересная концепция
2. не всем нравится gcc, люди надеются что другая реализация ц-крест-крест будет лучше (наивные)

Это же первый латентно-проприетарный компилятор, который противопоставляют как полноценную замену GCC.

>1. llvm - очень интересная концепция

Как я понял из тредов, её байт-код некросплатформенный. А был бы кроссплатформенный, то было бы интереснее, если производительность не терялась (не знаю, как там всё на самом деле), по сравнению обычной компиляцией в машинный код. И, насколько я знаю, llvm умеет использовать gcc вместо clang.

да gcc-измы испраивли и все.

gcc-змы в Qt? Оо Это в либе, которая собирается под студией и еще кучей проприетарных компиляторов?

Я так и не понял, яблочники вроде не так релизы гцц нумеруют как в линухе?!

И, насколько я знаю, llvm умеет использовать gcc вместо clang.

ага

> Как я понял из тредов, её байт-код некросплатформенный.

Вика с тредами не согласна:

В основе LLVM лежит промежуточное представление кода (Intermediate Representation, IR), над которым можно производить трансформации во время компиляции, компоновки и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.

> А был бы кроссплатформенный, то было бы интереснее, если производительность не терялась (не знаю, как там всё на самом деле), по сравнению обычной компиляцией в машинный код.

Она и не теряется, AFAIK. Наоборот очень большой потенциал по выжиманию всех соков из конкретной платформы. В отличие от «обычных» компиляторов, где бинари зачастую собираются под i686 без оглядки на специфику фактически доступного процессора.

> И, насколько я знаю, llvm умеет использовать gcc вместо clang.

Умеет. Вопрос лишь в том, сколько информации о коде теряется ввиду не-нативности gcc по отношению к llvm.

>Она и не теряется, AFAIK. Наоборот очень большой потенциал по выжиманию всех соков из конкретной платформы. В отличие от «обычных» компиляторов, где бинари зачастую собираются под i686 без оглядки на специфику фактически доступного процессора.

А надо с исходниками, собранными с оптимизацией под конкретную архитектуру сравнивать.

> А надо с исходниками, собранными с оптимизацией под конкретную архитектуру сравнивать.

Кто же их под твою конкретную архитектуру собирать-то будет?

мне пора спать

/me прочитал «Голос из танка» как «Голос из транка»

>/me прочитал «Голос из танка» как «Голос из транка»

Ну, ты не так уж далёк от истины… ;)

«транк» — это тот который trank или trunk?

Я сам соберу =) А если для чайников, то можно договориться по поводу формата пакетов для автоматической сборки, взяв за основу, например, src.rpm. Это явно легче создания целой виртуальной машины.

>>Кто же их под твою конкретную архитектуру собирать-то будет?

Я сам соберу =)

Таких как ты - 5% от всех линуксоидов и 0.05% от всех пользователей ПК. Собирай, того факта что «бинари зачастую собираются под i686 без оглядки на специфику фактически доступного процессора» это не изменит.

Эsrc.rpm. то явно легче создания целой виртуальной машины.

Считай, что байт-код это и есть src для процессоро-зависимого оптимизатора.

Чуть-чуть матчасти: http://habrahabr.ru/blogs/programming/47878/

>«транк» — это тот который trank или trunk?

Второе.

gentoo

> Однако из-за них отказались от gif

Кто это отказался от GIF? Если GIF использовать без LZW, то проблем с патентами не было. Впрочем патент на LZW давно истек.

>А чего все с этим clang так носятся? Что в нём такого особенного?

концепция - ждем появления подобного под GPL в gcc что должно ускорить его развитие.