Анонсирован (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/04250...) выпуск компилятора Clang (http://clang.llvm.org/), разрабатываемого в рамках проекта LLVM, отличающийся добавлением поддержки технологии SAFECode, позволяющей автоматизировать выявление ошибок, связанных с некорректной работой с памятью. Поддержка SAFECode включается через указание специальной опции и никак не влияет на поведение компилятора, когда данная опция не активна, т.е. представленный выпуск может быть использован в роли полной замены классической сборке clang/clang++. Для загрузки доступны (http://sva.cs.illinois.edu/downloads.html) как исходные тексты, так и готовые сборки для Linux и Mac OS X.
В отличие от инструментов подобных Valgrind, Clang с поддержкой SAFECode обладает следующими преимуществами:
- Он быстрее, так как не использует динамической трансляции исполняемого файла и может оптимизировать некоторые runtime-проверки;- Он более точен, так как знает расположение ...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/04250...
Новость: http://www.opennet.me/opennews/art.shtml?num=31533
Вот это замечательно! Clang - отличная штука. Теперь все свое стараюсь собирать им и gcc - очень много потенциальных ошибок выявляет.
А ты тоже "указатели инициализируешь", или даже не знаешь зачем это нужно (или не нужно)?
> (или не нужно)?Я сильно удивлюсь если он, умея пользоваться идой и колупать дизасмы, вдруг не знает как работать с указателями. Это было бы весьма оригинальное сочетание.
А где было написано про IDA и дизассмы? :)---
Я тоже немного не врубися... Накой инициализировать указатели?
Ну объявил я его, ну есть такой... а в нужном месте я ему чё-нить присвою.
В первом случае gcc матернётся, что есть не используемая переменная, а так,
забуду и появиться висячий. Хотя, gcc 4.6 тоже орёт, что переменная
инициализирована, но не используется.
> А где было написано про IDA и дизассмы? :)Этот человек замечен в ковырянии огороженных мотороло-техасских загрузчиков идой.
И вообще, ну что ты как маленький? Тынц: http://www.opennet.me/~XVilka
старичку gcc потихоньку приходится уходить на покой, еще лет пять и будет нормальный, прогрессивный компилятор, под нормальной лицензией. ура, елки-палки!
_нормальный_ компилятор на базе clang будет разве что под проприетарной лицензией, либо вообще не выйдет за пределы Apple.
Поэтому альтернативы gcc в ближайшие годы не видать :(
> Поэтому альтернативы gcc в ближайшие годы не видать :(Так обычно пытаются утешать себя те, кто с большим трудом в свое время кое-как освоили gcc, и уже не в состоянии переучиваться.
Скажем так, gcc будет жив до тех пор, пока живы люди, для которых альтернативы gcc действительно нет.
Ведь еще живы те, например, для которых нет альтернативы COBOL'у, fortran'у или DOS'овскому FoxPro.
Так что можете спать спокойно дальше.
clang - это внутренняя разработка Apple, и наружу выставляется лишь ее огрызок (в лучший традициях данной компании). Именно поэтому и выбрана такая лицензия (по аналогии с проприетарным андроидом, который якобы "открыт под лицензией Apache").А открытое сообщество по-прежнему будет довольствоваться этим чудом, которое даже бутстрапиться толком не умеет. А когда им пересоберут Фрю, с нее сбегут не только Яндекс и Рамблер.
Поэтому среди _открытых_ компиляторов альтернативы gcc нет и не будет. Есть лишь проприетарные нишевые решения, вроде icc.
> Есть лишь проприетарные нишевые решения, вроде icc.PathScale
Да, зря я за новостями не следил. Пропустил много интересного.
Это тоже не альтернатива. Он не понимает всего спектра платформ на которых работает gcc. Где там в pathcc arm mips ppc64 ia64? не говоря уже о microblaze tile и тп? нэту так что не альтернатива а нишевое решение которое еще и тупить ацки
> говоря уже о microblaze tile и тп?А как насчет MSP430, AVR, ARM и OpenRISC? Или мы должны выбирать альтернативы аж из целого х86 на все задачи, от мигания светодиодом в брелке до суперкомпьютеров?
1. Если clang это закрытая разработка представьте доказательства скрытия кода.
2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код - сажайте меня за изначилование, орган имеется.
3. Оно уже год как бутстрапится.
4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.
5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.Хотя бы не передёргивайте.
> 1. Если clang это закрытая разработка представьте доказательства скрытия кода.Эпплу все это надо сугубо для их xcode. И практически все разработчики шланга в эппле, что как бы намекает.
> 2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код -
> сажайте меня за изначилование, орган имеется.Эппл делом доказал на примере iOS, MacOS X и прочих что они не только имеют орган, но и зажимать вполне умеют. Достаточно вспомнить приколы с закрытием, открытием и опять закрытием и опять открытием дарвина :)))
> 3. Оно уже год как бутстрапится.
So what?
> 4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.
Сырой, грабельный и никем не поддерживаемый толком компилятор - оптимизма пользователям нацеленным на результат явно не добавит. Поскольку почти все разработчики в эппле а тому нужна макось а на бзди плевать, наивно ожидать что разработчики шланга бросятся решать проблемы оного применительно к бсд. Ну вот и будет у вас как обычно, третий сорт - не брак. Бздунам не привыкать быть третьим сортом на фоне проприетарщиков забирающих первый сорт себе. Проблема только в том что кастомеры не хотят третий сорт. Им первый подавай. Наверное потому и на линуксе с гцц в результате.
> 5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.
Они очень альтернативно одаренные альтернативы. А как насчет кодогенерации ну хотя-бы под новомодный ARM? А чтоб еще и с DSP-инструкциями и SIMD, если камень умеет?
> Хотя бы не передёргивайте.
Ну и к себе это примените, имхо.
>2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код - сажайте меня за изначилование, орган имеется.Аналогия некорректна.
Более корректная: возьмем два условных фаллоимитатора. Один можно использовать любых целях, включая изнасилование, другой - в любых целях, кроме изнасилования (механизм ограничения, допустим, предельно прозрачен). Цена и прочие характеристики одинаковы. Если человек приходит в секс-шоп и из этих двух выбирает первый, то его намерения вполне очевидны. Точно так же очевидны намерения гугла и яббла.
>4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.А никто и не говорил, что дело в компиляторе (сейчас там gcc по умолчанию, так что clang ни при чем).
Просто после перехода фри на clang там наверняка появится еще туева хуча проблем, начиная от множества хаков при make world и заканчивая кучей внезапных сегфолтов от разных программ.>5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.
А запорожец - реальная альтернатива 911 поршу, да.
Вы говорите о том, в чем ничего не понимаете. Пересобрал все свои проекты clangom без проблем. В некоторых с++ файлах получил вполне справедливые замечания о том, что негоже возвращать false где прототип int. Никаких "жутких проблем" не получил. Ну и опыт гугла мне как-то более показателен чем красноглазые форумные ламеры - http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html
> Так обычно пытаются утешать себя те, кто с большим трудом в свое
> время кое-как освоили gcc, и уже не в состоянии переучиваться.А чтобы переучиваться - через сколько лет он начнет генерить код под MSP430 допустим? Или там AVR? Или на кой черт переучиваться? GCC поддерживает больше архитектур и генерит более оптимизированный код как правило. А на архитектуру пусть бсдуны наяривают, как обычно.
>GCC поддерживает больше архитектур и генерит более оптимизированный код как правиловзаимоисключающие понятия
> взаимоисключающие понятияЧто значит - взаимоисключающие? Есть бенчи от того же фороникса и прочих, и в почти всех из них шланг радостно сливает. Почему-то он чаще сливает в разы чем сколь-нибудь заметно обгоняет гцц, как ни странно. А генерить код для всяких там армов и мипсов он вообще умеет только на бумаге похоже. Про всякие там аврки и вовсе даже речи не идет.
Остается вопрос: да напуркуа б осваивать компилер понимающий полторы архитектуры и с более плохой оптимизацией? И почему это надо засчитать за epic win?
оптимизация у clang лучше.А вобще хватит кормить троля - пошел бы ты почитал что ли документацию.
> оптимизация у clang лучше.Нет, оптимизация лучше у gcc. clang и компилировать-то толком не умеет, куда уж ему оптимизацией заниматься.
>> взаимоисключающие понятия
> ... Есть бенчи от того же фороникса ...О да :-)) это это крутые бенчи :-)) круче тока бенчи от intel :-))
> О да :-)) это это крутые бенчи :-)) круче тока бенчи от intel :-))Если вы считаете что такие-то бенчи плохие, ну ок: произведите бенчи лучше, которые будут "хорошие". И опубликуйте результаты с внятным описанием параметров тестов, чтобы можно было проверить что вы не врете. И имейте в виду что мы без проблем вычислим потуги подыграть тем или иным кандидатам, так что даже и не пытайтесь.
Субъективно шланг генерит код похуже GCC в среднем по больнице, а на некоторых неудобных ему случаях отхватывает epic fail, сливаясь в 2-3 раза без особых причин, что у фороникса на тестах прекрасно видно. Какой-то плохо-предсказуемый и недопиленный оптимизатор, если называть вещи своими именами.
FORTRAN не трогать, а если трогать, тогда объяснте и что лутше для научных рассчетов?
Haskell?
clang уже есть и он более чем нормальный. Когда в gcc будет статический анализ, нормальное LTO, да просто хотя бы нормальные сообщения об ошибках, можно будет говорить, а пока clang его заруливает.
угу. заруливает. особенно если смело написать:
>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linuxа чуть капнёшь по ссылке, и:
>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :D
> угу. заруливает. особенно если смело написать:
>>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linux
> а чуть капнёшь по ссылке, и:
>>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.
> не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :DВ данном случае речь идет о gcc-змах. А раз clang не gcc, то и обработать его правильно не сможет. Уж это Вы должны суметь понять.
> суметь понять.Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И вам проще и всем остальным. Правильное решение конечно в стандарт втолкать, но ждать еще 10 лет очередной стандарт - как-то слишком уж геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)
>> суметь понять.
> Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из
> них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо
> воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И
> вам проще и всем остальным. Правильное решение конечно в стандарт втолкать,
> но ждать еще 10 лет очередной стандарт - как-то слишком уж
> геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)А вопрос не в фичах, а "упрощённой модели" реализации. Взять например наследование темплейтов: "http://stackoverflow.com/questions/3829040/scope-problems-in.... В clang-е эта хрень реализована верно и он ошибку видел, а gcc компилил как есть и не заморачивался.
>А вопрос не в фичах, а "упрощённой модели" реализации.а вопрос не в фичах и "упрощённой модели" реализации.
вопрос в сборке всего того ПО, которое есть на данный момент.
и если кому то сильно жмут гнушные утилиты, то это его проблемы - я же просто возьму и соберу тем, что собирает без проблем.
зыж
самое время назвать меня красноглазым, угу.
да да. есть идиоты которые пишут код под конкретный компилятор и удивляются почему при смене версии gcc все перестало работать.
Есть те кто пишут переносимый код - и тогда собирается даже clang.Ты видимо относится к первым.
Вам к жабистам. Хотя и у них переносимость не всегда возможна.
> Взять например наследование темплейтовв C, ага.
>> суметь понять.
> Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из
> них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо
> воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И
> вам проще и всем остальным. Правильное решение конечно в стандарт втолкать,
> но ждать еще 10 лет очередной стандарт - как-то слишком уж
> геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)Закон не запрещает. Но зачем, если есть стандарт, который надо придерживаться. Или Вы хотите сказать, что хаки под IE - тоже хорошо?
> Закон не запрещает. Но зачем, если есть стандарт, который надо придерживаться. Или
> Вы хотите сказать, что хаки под IE — тоже хорошо?если gcc добавляет к стандарту удобные плюшки — я лично буду использовать эти плюшки. стандарты пишут не боги (ох, далеко не боги). и если мне надо ждать ещё 10 лет, чтобы в стандарт внесли очередную удобную плюшку — в анус такой стандарт.
gcc — сам по себе стандарт, de facto. если кому-то нравится быть пуристом — на здоровье, конечно; а я лично мазохизмом не страдаю в такой степени.
к тому же аналогия неверная: gcc *дополняет* стандарт, а IE просто тупо неверно реализует. разница ощутимая.
так что бедняши, которым религия запрещает использовать gcc — ССЗБ.
>[оверквотинг удален]
>> Вы хотите сказать, что хаки под IE — тоже хорошо?
> если gcc добавляет к стандарту удобные плюшки — я лично буду использовать
> эти плюшки. стандарты пишут не боги (ох, далеко не боги). и
> если мне надо ждать ещё 10 лет, чтобы в стандарт внесли
> очередную удобную плюшку — в анус такой стандарт.
> gcc — сам по себе стандарт, de facto. если кому-то нравится быть
> пуристом — на здоровье, конечно; а я лично мазохизмом не страдаю
> в такой степени.
> к тому же аналогия неверная: gcc *дополняет* стандарт, а IE просто тупо
> неверно реализует. разница ощутимая.вот IE просто дополняет стандарт удобными ему вещами, забывая реализовать что не удобно - как и поступает gcc. так за что вы не навидете IE ? Великий Столман завещал его ненавидеть и любить маленьких мальчиков?
> вот IE просто дополняет стандарт удобными ему вещами, забывая реализовать что не
> удобно - как и поступает gcc.gcc довольно неплохо реализует стандарты, что c99, что C++ 11. А то что он реализует что-то сверх того - гм, а что, предлагается еще годков 15 ждать пока примут c(++)2025 какой-нибудь? Если б ишак реализовывал стандарты так как они описаны и более-менее целиком, к нему бы никто никаких претензий не предъявлял бы по части стандартов.
>В данном случае речь идет о gcc-змах.Речь идет о внутренних ошибках компилятора и проблемах с обработкой массивов переменной длины, уж это вы должны суметь прочитать.
> угу. заруливает. особенно если смело написать:
>>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linux
> а чуть капнёшь по ссылке, и:
>>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.
> не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :DВообще то ядро линукса это огромная куча кода драйверов написанного непонятно кем. Многое железо уже умерло и так так девайсов тех уже нет переписывать это непланируется ...
> статический анализ, нормальное LTO,Блин, почему-то в целом оптимизация гцц - лучше. Как именно это достигнуто, мне как программисту вообще до лампочки, LTO там это сделает или что-то еще.
> да просто хотя бы нормальные сообщения об
> ошибках, можно будет говорить, а пока clang его заруливает.Не хочу ничего сказать, но у меня почему-то нет проблем с пониманием ошибок и варнингов выдаваемых gcc. Наверное я что-то делаю не так. Может, надо потупеть на 20 пунктов?!
> у меня почему-то нет проблем с пониманием ошибок и варнингов выдаваемых gccboost'ом давно пользовался? Что-нибудь серьезное на плюсах вообще писал (на плюсах, а не на C с классами)?
qt, кеды и тд.
они вообще ещё не собираются толком шлангом.
зыж
и тут же вдогонку:
>При оценке производительности демонстрационного браузера на основе Qt и QtWebKit, собранного при помощи Clang, на выполнение тестов SunSpider ушло 415.4мс, в то время как QtSDK/64bit в сборке Nokia выполняется за 360.0 мс (замедление на 13%).и
>Последняя версия Clang успешно собирает Boost и проходит большинство тестов.а меньшинство видимо вообще не проходит?
и как, опять без пруфов будете кидаться словами?
> boost'ом давно пользовался?я вот, к счастью, никогда.
> Что-нибудь серьезное на плюсах вообще писал (на плюсах, а не на C с классами)?
а что, на плюсах «пишут серьёзное»? в *серьёзных* проектах гайдлайнами цпп обрезан как раз до «сей с классами».
> boost'ом давно пользовался?Не, спасибо, не люблю переростков. Но вообще-то у шланга проблем с сборкой плюсатого софта выше крыши, если уж на то пошло.