Компания PathScale анонсировала (http://www.pathscale.com/ekopath4-open-source-announcement) открытие исходных текстов высокопроизводительного набора компиляторов EKOPath 4 (http://www.pathscale.com/ekopath-compiler-suite), совместимого с GCC и удовлетворяющего требованиям стандарта ISO C99/C++ 2003. Кроме компиляторов С и С++, в комплект также входят: компилятор для языка Fortran 90/95/2003, совместимый с GDB отладчик PathDB, ассемблер PathAS, набор run-time-компонентов и стандартные библиотеки. Компилятор уже достаточно давно используется в промышленных системах, отвечает индустриальным требованиям к стабильности и надежности, поддерживает большое число дополнительных оптимизаций для платформ Intel 64 и AMD64, включает поддержку технологий Intel MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AMD SSE4A и AVX.Код проекта открыт под лицензией GPLv3 и доступен (https://github.com/path64/) в GitHub. Бинарные сборки подготовлены для Linux (http://c591116.r16.cf2.rackcdn.com/ekopath/...
URL: http://www.pathscale.com/ekopath4-open-source-announcement
Новость: http://www.opennet.me/opennews/art.shtml?num=30858
> удовлетворяющего требованиям стандарта ISO C99/C++ 2003Верится с трудом. В первый раз слышу о компиляторе, целиком удовлетворяющем требованиям стандарта С++.
Хотя поддержка С99 - довольно вкусная фича. Не то чтобы мне действительно не хватало тех возможностей С99, которые предоставляет gcc, но приятно знать, что в случае необходимости поддержка будет предоставлена)
И, конечно, столь ненавистная многими "вирусная" лицензия GPLv3 - тоже приятный бонус)
Главное, что настал конец безальтернативности GCC в опенсурс.
Теперь компиляторы начнут появляться как грибы после дождя.Остальное мелочи.
Ой, как бы не понадобилось каждому проекту прикладного СПО по своему компилятору.
Это к тому, что такая ситуация не способствует совместимости.
> Ой, как бы не понадобилось каждому проекту прикладного СПО по своему компилятору.
> Это к тому, что такая ситуация не способствует совместимости.Ой, какой ужас!
В мире не бывает идеальной совместимости.
А идеальный компилятор, подходящий для всех проектов - это такая же утопия, как идеальная совместимость.С другой стороны, уровень совместимости - это выбор самих авторов проекта. Они должны иметь свободу решать, что им важнее - совместимость или какие-то особенные качества конкретного инструмента.
Наконец, совместимость по компиляторам, если говорить конкретно про С/С++, определяется не выбором компилятора, а выбором опций компилятора. Пора бы некоторым уже это знать, прежде чем рассуждать о совместимости.
Огромное количество проектов уже давно пишутся не под C/C++, а под совсем другие языки, с несовместимыми трансляторами. И ничего живут как-то. Вы просто не в курсе.
И вообще. Проблемы с совместимостью компиляторов решаются так же, как совместимость между процессорами и ассемблерами. Уже все для этого придумано, даже можно ничего нового не изобретать, разве что улучшать.
Просто некоторым не хватает умения абстрактно мыслить, чтобы это осознать. А это умение - одно из важнейших в области информационных технологий.
Угу, это такой конец конечно. Поддерживает полторы архитектуры аж. И конечно же о победах протрубили, но наверняка забыли указать в каких бенчмарках они проиграли в 2 раза, как обычно. Т.е. если скомпилить среднестатистическую прогу - вероятно выигрыш в 2 раза мы не увидим ;). Хотя +1 компилер на выбор - в общем то неплохо, как ни крути.
Вы видимо не в силах осознать разницу между словосочетаниями
"конец компилятору" и "конец безальтернативности".
> "конец компилятору" и "конец безальтернативности".Чтобы стать реальной альтернативой - надо, очевидно, реализовать сравнимый функционал. Ну вот например, thttpd не является альтернативой nginx. Хотя оба как бы httpd. Проблема в том что у nginx найдется функционал, которого у thttpd нет. Поэтому равноценно заменить - не получится.
Если для вас что-то не является альтернативой чему-то - это никак не означает, что у всех такое же положение, как у вас.
> Чтобы стать реальной альтернативой - надо, очевидно, реализовать сравнимый функционал. Ну вот например, thttpd не является альтернативой nginx. Хотя оба как бы httpd. Проблема в том что у nginx найдется функционал, которого у thttpd нет. Поэтому равноценно заменить - не получится.Кроме того, что вы
не видите разницы между "концом существования" и "концом безальтернативности",
вы еще не видите разницы
между "быть альтернативой" и "быть (одним и тем же)/одинаковым".
Теперь GCC-шникам не отвертеться от запросов "посему мой код дак медленно рабтает". Раньше отмазывались тем что проект сложный и уже все давным давно оптимизировано.
> "посему мой код дак медленно рабтает"Косяки gcc прекрасно видны в ассемблерном выводе, никогда не отвертеться было.
> Косяки gcc прекрасно видны в ассемблерном выводе, никогда не отвертеться было.Более того, почему-то любой компилятор по сравнению с нормальным програмером генерит дичайший г0вн0к0д. Если надо локально оптимизнуть некий участок - нормальный ассемблерщик уделает компилятора в разы. На локальном куске, разумеется. На большой программе компилятор может лучше распределять регистры.
Если не трудно, Приведите пример с "разами" vs. gcc-4.6-O3 -march native и т.п. Без сарказма, просто интересно.
Не открой они исходники о них бы так никто и не узнал.
Кому было нужно - знали.Такие вещи как Open64, Pathscale ENZO, Intel Compiler - это энтерпразный сектор. И компиляторы затачивались в основном под параллелизацию и числодробильню.
Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно, о них знают те, кто компилирует программы для космических проектов, топовых кластеров, военных проектов и атомных станций.
/me снимает лапшу с ушейКончайте это бла-бла-бла с придыханием, это лучше подойдет Рейзер-, Ваком- или Эппл-фанбою. Розовых слоников не бывает. Есть продукт, возможно удовлетворяющий некоторому набору требуемых характеристик и скорее всего просасывающий в остальном, а то что оно бороздило Большой театр - это вы менеджероте и хаброте расскажите, им это интересно.
Ну работал я в свое время (года 4 назад) с PathScale-овским компилятором. На моих задачах он давал 10-15% над gcc. С совместимостью все было лучше, чем у интела, но не 100%-но гладко. Интересная штука, но не ужас-ужас какая интересная.
> Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно,Сколько апломба. А по факту, почему-то самым "ынтерпрайзным" и впаривают вечно черт знает что.
> о них знают те, кто компилирует программы для космических проектов, топовых
> кластеров, военных проектов и атомных станций.Вы просто этих военных наверное не видели. Обычно это наиболее тупые и деревянные из всех возможных кастомеров. Не только отечественные, кстати - они такие везде ;). А что до атомных станций, поговаривают что на Фукусиме кроме всего прочего возможно внесла лепту и система управления, перепутавшая полный слет питания с разрывом трубопровода (правда маленький баг?) и срубившая по этому поводу контур аварийного охлаждения реактора (как мило!). А пока там до персонала в суете дотумкало что клапан аварийной системы охлаждения закрыт - понятное дело, реактору лучше не стало и вообще, времени на разбор ситуации не осталось толком. Атомные станции, говорите? По-моему, пора уже показательные расстрелы вводить. Чтобы поменьше пальцевали и побольше отвечали головой.
> Продукты PathScale - это высший пилотаж, смертным о них знать не обязательно,
> о них знают те, кто компилирует программы для космических проектов, топовых кластеровТо-то покупают мерзостный PGI.
А как у него с cxx0x?
>Код проекта открыт под лицензией GPLv3Однако, как я понимаю прямое заимствование кода в GCC будет невозможным из-за политики фонда?
Наверняка, Столман не включит без передачи кода.
требуется передача прав на код, просто лицензии не достаточно
И потом они ругают других за несвободу...
Ну, как минимум они у других пока свободу не отнимали. Любой инструмент можно использовать во благо или во зло.
> И потом они ругают других за несвободу...Они уже пользуют свободу, которую им дал фонд. Форк выпускают. Вот пусть его сами и тащат-ментейнят до собственного изумления -- _свобода_.
Какие ещё вопросы к FSF по поводу свободы??
кто «они»? какой «форк»? O_O
Упс... Десит-на. """EKOPath is a 'fork' of SGI's Pro64х[...]"" http://www.phoronix.com/scan.php?page=news_item&px=OTU2OAПрошу прощения, обманулся та-а-акой gcc-совместимостью.
> Однако, как я понимаю прямое заимствование кода в GCC будет невозможным из-за
> политики фонда?нет, из-за того, что архитектуры компиляторов наверняка разные.
Теперь Линуксы будут еще шутрее. Приятный сюрприз. Может у них еще есть и микроядро Linux-совместимое?
какие хорошие новости.GPLv3 ? кое-кто уже наверняка мылит веревку и идет вешаться )
Изя и другие латентные вантузятники?
я скорее имела ввиду товарищей активно вопящих что GCC им не нужен и ядро и базовый юзерспейс своей *BSD они уже почти собрали pcc/clang/ или чем-нибудь еще )
гцц не плюет на стандарты, гцц дополняет стандарты. слэнг обеспечивая поддержку гцц-расширений, получается, тоже плюёт на стандарты?
А стандарты GNU - это стандарты де факто. Вот большинство разработчиков СПО на них и ориентируются. Ну а желающие собирать "более стандартным" clang пусть пишут патчи.
-std=gnu99
Кстати, да, pcc/clang могут в смешном положении оказаться.
>я скорее имела ввиду товарищей активно вопящих что GCC им не нужен и ядро и базовый юзерспейс своей *BSD они уже почти собрали pcc/clang/ или чем-нибудь еще )1. С открытием исходников PathScale GCC не стал более нужным.
2. С открытием исходников PathScale clang/pcc не стали хуже
3. С открытием исходников PathScale 99% дистрибутивов линукса все так же буду собирать ядро и мир GCC.
4. Патчи из PathScale с большой долей верноятности не попадут в GCC либо в силу архитектурных отличий либо "не кошерно".
5. Интересно посмотреть PathScale vs pcc не на числодробилках.Так с чего бы веревку мылить? Хотят хлопцы иметь в базовой ситеме компилятор под СОВМЕСТИМОЙ лицензией. clang и pcc вполне себе достойный проекты. А Вы говорите как будто это что-то плохое.
Если вам такое мерещится, фанатьё именно вы :))
Intel C/C++
эти навряд ли ;) у них своя ниша, хотя пусть тоже может подумают чтобы что-нибудь открыть
> подумают чтобы что-нибудь открытьДействительно, а то ни себе ни людям: оно может генерить нормальный код, но это успешно нивелируется тем что оно гадит процессорам амд + жутко глючное: каждая вторая программа собранная интелским компилером почему-то начинает испытывать совершенно неочевидные глюки.
>нивелируется тем что оно гадит процессорам амдЭто как?
> Это как?Одно время тут был разбор полетов: интел уличили в неиспользовании новых SSE команд (которые есть в амдшных процах) при работе на амдшных процах. А на интеле - использовались. В memcpy, чтоли. Легко победить на стометровке! Особенно если сопернику привязать к ноге пушечное ядро. Что интел и заимплеметил.
Supported Platforms
Stable:
Novell, Red Hat, Oracle, Ubuntu, FreeBSD
Beta:
Windows, Mac
Страно както Ubuntu есть а Debian куда делся?
А вы задумайтесь, почему например Red Hat есть, а Fedora нет?Да просто тут все - это список дистрибутивов, предлагающих серверные решения уровня enterprise, с сертификацией и поддержкой. Поэтому попадают Red Hat и Oracle, но не Fedora. Debian ведь не предлагает никаких серверных решения с гарантиями - а Ubuntu Server таковым является: существует поддержка от производителя, программы сертификации и прочее.
(как тут оказался FreeBSD, не берусь сказать..)
> Debian ведь не предлагает никаких серверных решения с
> гарантиями - а Ubuntu Server таковым является: существует поддержка от производителя,
> программы сертификации и прочее.Извините, что не в тему, зато про Ubuntu:
У нас десятки серверов под Ubuntu Server, используем только LTS (8.04, 10.04). Несколько серверов используют технологию LXC. И что вы думаете произошло недавно? Прилетело обновление 2.6.32-32, поломавшее поддержку Network Namespace в LXC!!! Это нарушение всех принципов, ломать ABI внутри релиза, да ещё и LTS. Canonical предложили обновить ведро до linux-image-server-lts-backport-maverick - ок, конечно это не совсем то, что ожидалось, но хотя бы что то. Но тут же выяснилось, что самые свежие обновления утилит LXC с бекпортом не дружат! Хорошо, что мы поддерживаем собственный репозиторий (спеллчекер предложил заменить на "суппозиторий" что кагбэ намекает), и нам не составило труда сделать бекпорт утилит из более поздних (не LTS!!!) выпусков. Короче это бред какой то... Вот вам и "серверные решения уровня enterprise, с сертификацией и поддержкой". Я понимаю, что этим сообщением поднасрал любимому дистру (он у нас и на воркстейшнах, у меня и на всём где можно дома), но возможно кому то это сообщение окажется полезным.
Вдогонку, чтобы было понятно откуда негодование:За ночь (часы наименьшей нагрузки) нужно было перевезти десяток серверов. Контейнеры благополучно перелезли по сети на хост-машины в новом датацентре, а после установки перевезёных в эту ночь серверов отказались перелезать обратно. Время поджимает, скоро нагрузка даст о себе знать, а тут такая засада - попробуй догадаться, что как раз после включения хост-машин поднялось то злополучно обновлённое ядро 2.6.32-32, а потом всё это ещё и устаканить после бессонной ночи.
Ну вы же должны понимать :)
Есть разница между декларированием поддержки и некоторых гарантий (кстати, возможно, гарантии предоставляются только тем, кто купил поддержку?) и реальным уровнем поддержки.Скажем, у редхата косяков такого уровня, вроде, не бывает. Хотя может и можно нарыть какой-нибудь случай. Но на практике редхатовские "гарантии" оказываются более работоспособными, чем убунтовские. Ну вот так сложилось. Но не будут же вам заявлять это в убунте, что мол у нас гарантии не такие хорошие?..
Просто есть разница между реальной жизнью и формальными заявлениями. В реальной жизни, например, Debian Stable на сервере может оказаться надежнее и менее проблематичным, чем Ubuntu Server со всеми гарантиями последнего и при работе на сервере, сертифицированном под убунту. Но тем не менее производитель будет поддерживать убунту в первую очередь - есть гарантия, есть ответственные люди, доступна поддержка - в отличие от дебиана, где с разработчиков взятки гладки - как вышло, так и работает. Корелляция между гарантиями и реальной стабильностью обыычно есть, но не всегда :)
А что до реальной ситуации, то сейчас, конечно, нужно брать редхат, если требуется стабильность. Кстати, нормальные LXC там будут; пока есть как technology preview, т.е. без гарантий. Но это не означает, что у разработчиков ubuntu server руки кривые и т.д... просто сколько лет редхат в этом бизнесе и сколько убунта?.. Да и штат разработчиков и тестеров с бюджетом у редхата о-го-го будет, убунта за свой сервер явно и десятой доли этого не получает. Со временем, думаю, и убунта сервер станет весьма пристойным продуктом, соответствующим своим заявлениям. Просто пока рано еще.
> Ну вы же должны понимать :)Я всё понимаю, но поплакаться в жилетку таки хотелось :)
> Я всё понимаю, но поплакаться в жилетку таки хотелось :)Нормальные админы до того как рубить с плеча, тестируют вещи типа перемещения машин и обновлений на небольшой тестовом окружении. Если все прошло гладко - ок, делается на основном. А вы сами себе злобный буратино. Каноникал конечно облажались, но вы ничем не лучше.
>> Я всё понимаю, но поплакаться в жилетку таки хотелось :)
> Нормальные админы до того как рубить с плеча, тестируют вещи типа перемещения
> машин и обновлений на небольшой тестовом окружении. Если все прошло гладко
> - ок, делается на основном. А вы сами себе злобный буратино.
> Каноникал конечно облажались, но вы ничем не лучше.Админ - теоретек? Если внимательно читали, половина машин в предыдущую ночь переехала удачно.
Правильно сделал. Описал подробно, что за косяк и с чем вышел. Мы теперь знать будем, как бывает.
какая печальная история. сервер на убунте шовышовынивжисть.
"будут ещё шустрее"?
Он, ведь, "компилирует быстрее", а не "полученные файлы работают быстрее".
http://www.phoronix.com/scan.php?page=article&item=pathscale...Садись на диету.
Если он GCC совместимый как им подменить GCC?
погоди, проприетарщики "медленно разворачивают корабль в сторону опенсорса", дня через два будут актуальные исходники, потом хлынет волна патчей от сообщества, потом уже и нормальная замена gcc. Пока доступны бинарники и то полуработающие.
Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3. Опции дефолтные
> Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3.
> Опции дефолтныеНу просто бравые проприетарные перцы как обычно упомянули только о своих сильных сторонах. Забыв упомянуть остальные.
> Собрал xz с ним, получилось медленнее на 3%, чем с gcc 4.4.3.
> Опции дефолтныедавай подробнее медленнее собиралось или медленнее выполняется? размер получившегося кода? интересно таки!
Say RMS gb? :) Солнце всходит и заходит и - зашло. GCC больше не уникален. Теперь окончательно :)На самом деле, теперь по логике вещей ключевым и сопряженным проектам fsf нужно асап вносить в код как можно больше гнусизмов и пр. мелких радостей. Под любой ширмой. Чтобы все-таки альтернативы альтернативами но без gcc - никуда. Как кому-то без винды. Ибо что там осталось то полезного без всеми нами любимого (без сарказма) gcc? Ничего :)
> Say RMS gb? :) Солнце всходит и заходит и - зашло. GCC
> больше не уникален. Теперь окончательно :)хочу увидеть сабжевый компилятор для ia-32. а также для (тут перечисление архитектур, поддерживаемых gcc). так что пока уникален. и надолго, думаю.
> хочу увидеть сабжевый компилятор для ia-32. а также для (тут перечисление архитектур, поддерживаемых gcc). так что пока уникален. и надолго, думаю.Если есть реальная для x86_64 причем не столько C сколько C++ со всеми хотя бы низкоуровневыми примамбасами типа stl/boost/ACE/etc - это уже большой и жирный гвоздь в крышку гроба :)
Не сомневаюсь, что ia32 все ещё актуальна в своих секторах. Но куда более актуальна AMD64. И чем дальше тем больше. Найти сегодня сугубо 32х разрядный интел - это ещё поискать нужно. Корки и те давно уже своё отживают. Хороший был зверь. О чем тогда разговор? Про сервера молчу - какой там нафик ia32? Даже не смешно. Но, повторюсь, верю, кому-то актуально. Так что и спорить не буду.
лично меня 64 бита не волнуют. и ещё много лет волновать не будут. так что для меня этот компилятор совершенно бесполезен. увы.
Должны волновать не биты, а дополнительные регистры в x86_64.
> Должны волновать не биты, а дополнительные регистры в x86_64.а меня и регистры не волнуют, потому что я не собираюсь это всё использовать. x86 давно помер и очень противно воняет.
> лично меня 64 бита не волнуют. и ещё много лет волновать не
> будут. так что для меня этот компилятор совершенно бесполезен. увы.А 32-битный х86 уже по сути умер - нынче 4 Гб и более совершенно обыденное дело. IA32? Это прошлый век. В 21 веке как максимум 32-битным имеет право быть какой-нибудь маложручий арм в телефоне.
> А 32-битный х86 уже по сути умер - нынче 4 Гб и
> более совершенно обыденное дело. IA32? Это прошлый век. В 21 веке
> как максимум 32-битным имеет право быть какой-нибудь маложручий арм в телефоне.твоё бесценное мнение очень важно для меня.
Капитан напоминает, что PAE давным-давно позволяет не только 4 Гб и более, но даже 64 Гб. Впрочем, некоторые материнки до сих пор не поддерживают 4 Гб оперативы. Включая, что смешно, те, которые поддерживают только 64хбитные процессоры. Советую Вам, как человеку несомненно нуждающемуся в более 4Гб оперативной памяти, проверить свою материнку)
> А 32-битный х86 уже по сути умер - нынче 4 Гб и более совершенно обыденное дело.прочти про PAE.
А Когда прочтёшь вернись и расскажи нам о преимуществах 64 бит и о том, ради чего ты собираешься закрывать глаза на недостатки.
сабжевый компилятор поддерживает x86_32бинарной сборки правда не сделали (?)
попытка собрать с гита пока неудачна, вероятно гит в процессе обновления, много битых файлов.
> сабжевый компилятор поддерживает x86_32пока что дали только 64 бита. вот дадут сборку на 32 -- посмотрим, как оно справляется.
> ... тут перечисление архитектур, поддерживаемых gcc ...Увы, но архитектуры умирают быстрее GCC :)
Да они никак и не претендуют на роль замени GCC, люди решили поменять модель бизнеса растивая побольше заработать... желаю им успеха, нам от етого толька лучше будет. Даеш больше компиляторов, хороших и разных.
Вот клёвая приблуда (была, два года без апдейтов), для перебора вариантов флагов компиляции,
компиляция, и сравнение результатов, (гентушники должны кончить в этом месте). :)http://sourceforge.net/projects/pathscale-ici/
This is an Interactive Compilation Interface (ICI) to access and modify internal
PathScale compiler optimization decisions to tune applications at fine-grain
level for performance, size, power consumption, architecture-compiler DSE, etc.
acovea давно уже есть и гентушники давно уже на нее забили, как и почти все остальные впрочем тоже
А MPlayer получица им собрать???
> А MPlayer получица им собрать???Вы не получите большого выйгрыша - все части, где профайлер показывал, что есть смысл ускорять уже переписаны на ассемблере руками. Т.е. компилятор C на них не влияет, а от ускорения остального эффекта почти не будет. Посмотрите те же форониксовские тесты, у ffmpeg зависимость от компилятора минимальная.
Хотя если вы используете какой-то редкий фильтр и он не оптимизирован, то эффект может быть. Особенно если в компиляторе есть хороший автовекторизатор - в gcc он не очень, да и глючит, поэтому ffmpeg / mplayer его вообще отключают - пользы нет, а баги появляются.
сабжевый компилятор не поддерживает ARM, так что сугубо нишевая штука
> сабжевый компилятор не поддерживает ARM, так что сугубо нишевая штукаподдерживает.
Supported architectures are:
x86_32
x86_64
mips_32
mips_64
rsk6_32
rsk6_64
arm
впрочем как выяснилось не поддерживают, оно пытается собраться, но не собирается,
ждут патчей от коммьюнити )
Что смешно, оба мира - PathScale и FOSS ну никак не пересекаются! Вопрос: зачем эти заигрывания? Те, кто писал под промышленные системы, тому исходники PS не нужны - он просто пишет свои прошивки. А опенсорсу не нужна абсолютно гетерогенная система PS, т.к. заимствования кода тут минимальные. Ну, разве что заменят ГЦЦ на ПС, но для этого придётся ПС заточить подо все костыли ГЦЦ! Причём это будет уже третий компилер, разрывающий общие усилия разрабов. ЗАЧЕМ?
> третий компилер, разрывающий общие усилия разрабов. ЗАЧЕМ?не разрывайся, кто ж тебя заставляет? или ты считаешь, что сейчас весь народ бросит пилить gcc, llvm/clang, pcc и так далее, и вместо этого дружно ломанётся пилить новое?
открытый качественный компилятор, да ещё под GPL — это хорошо.
или по-твоему, надо позакрывать все проекты, у которых уже есть аналоги, и оставить один Самый Главный Проект? проспись, что ли.
> ЗАЧЕМ?Ну, в последнее время дружно всех ломают. А код, сгенерированный этим компилятором, якобы, в серьёзных проектах применяется. А кто как ни широкая общественность может подтвердить, ну или точне не обнаружить ляпсусов по безопасности генерируемого кода? И таким образом они повысят доверие в "свой" продукт.
GPLv3 - это win!
Про ARM ни слова. И эти робяты претендуют на энтерпрайзность?
А компиляция С++ шаблона класса из отдельного файла у них реализована?
Кому это надо? Template export практически никакой компилятор не поддерживает, поэтому использовать эту фичу — такой же vendor lock-in как GCC-измы.
Годная новость... Ещё один свободный набор компиляторов не помешает. Да и уровень оптимизаций у него впечатляет. Думаю, что это событие повлияет на развитие и GCC с LLVM. От конкуренции всем профит будет.
К сожалению, это действительно нишевый продукт. Поддерживаются только x86-64 и MIPS (желающие могут почитать документацию на сайте). Кроме того, GCC уже практически поддерживает C++0x, а этот - нет, и далеко не факт, что его внутренняя структура позволяет легко такую поддержку добавить.Думаю, они его открыли, чтобы уменьшить стоимость разработки. Поддерживать разработку качественного полномасштабного компилятора C++ в одно рыло - сейчас очень дорогое удовольствие. И в этом смысле GPL - самое правильное решение: BSD/MIT обладают многими достоинствами, но стимуляция к разделению стоимости разработки к ним не отностися. Это, кстати, почему clang, скорее всего, не имеет перспектив.
Всё это не отменяет того, что факт положительный и продукт, очевидно, качественный.
> Это, кстати, почему clang, скорее всего, не имеет перспектив.Не, ну почему же, он имеет перспективы у эппла и прочей макосятины. Они будут кушать в одно лицо и ни с кем не делиться. Зато все из себя гордые и проприетарные.
Что-то я сомневаюсь что мотивом открытия послужило желание сэкономить на разработке. Посмотрел цени на их сайте, вряд ли они испытывают проблемы с деньгами...Кстати у них там имеется еще PathScale® ENZO он остался закрытым ведь да?
да когда же уже выложат полные сорсы!?
задолбали - не собираецо оно из гита!
ненависть!
> да когда же уже выложат полные сорсы!?
> задолбали - не собираецо оно из гита!
> ненависть!Сказали, что еще несколько дней ждать пока все что запланировали откроют. Они порциями открывают, поэтому в git-e сейчас бардак.
Мда у меня тоже не собираеца, шо за ерунда такая...[ 1%] Built target iberty
[ 1%] Built target decnumber
[ 1%] Built target cpp
[ 1%] Built target spin-x8664
[ 1%] Built target gspin-x8664
[ 2%] Built target genoptions
[ 2%] Built target gencheck
[ 2%] Built target gengtype
[ 2%] Built target genmodes
[ 2%] Built target gen
[ 2%] Built target genopinit
[ 2%] Built target genpreds
[ 3%] Built target gcov_iov
[ 3%] Built target genflags
[ 3%] Built target genattrtab
[ 3%] Built target genoutput
[ 3%] Built target genautomata
[ 3%] Built target genattr
[ 3%] Built target genextract
[ 3%] Built target gengenrtl
[ 3%] Built target genconfig
[ 3%] Built target genemit
[ 3%] Built target genpeep
[ 3%] Built target genrecog
[ 3%] Built target genconditions
[ 3%] Built target genconstants
[ 3%] Built target gencondmd
[ 3%] Built target gencodes
[ 7%] Built target backend-x8664
[ 7%] Built target cc142-x8664
[ 8%] Built target cc1plus42-x8664
[ 8%] Built target crtbegin-x86_64
[ 8%] Built target crtbeginS-x86_64
[ 8%] Built target crtend-x86_64
[ 8%] Built target crtendS-x86_64
[ 8%] Built target table
[ 8%] Built target driver_gen_sources
[ 9%] Built target pathcc
[ 9%] Built target pathcc_deb
[ 10%] Built target pathcc_rpm
[ 10%] Built target pathcc_sle10
[ 10%] Built target stageit-driver
[ 10%] Built target cif
[ 10%] Built target cmplrs
[ 10%] Built target tag_tree_build
[ 10%] Built target tag_attr_build
[ 11%] Built target dwarf-x8664
[ 12%] Built target elf
[ 13%] Built target elfutil
[ 13%] Built target rtkutils
[ 13%] Built target gensyn
[ 13%] Built target gen_util-x8664
[ 13%] Built target isa_gen-x8664
[ 13%] Built target isa_gen_topcode-x8664
[ 13%] Built target isa_subset_gen-x8664
[ 13%] Built target targ_isa_subset-x8664
[ 13%] Built target isa_registers_gen-x8664
[ 13%] Built target targ_isa_registers-x8664
[ 13%] Built target abi_properties_gen-x8664
[ 13%] Built target isa_properties_gen-x8664
[ 13%] Built target targ_isa_properties-x8664
[ 13%] Built target isa_enums_gen-x8664
[ 13%] Built target targ_isa_enums-x8664
[ 13%] Built target isa_lits_gen-x8664
[ 13%] Built target targ_isa_lits-x8664
[ 13%] Built target isa_operands_gen-x8664
[ 13%] Built target targ_isa_operands-x8664
[ 13%] Built target si_gen-x8664
[ 13%] Built target barcelona_si_gen
[ 13%] Built target barcelona
[ 13%] Built target core_si_gen
[ 13%] Built target core
[ 13%] Built target em64t_si_gen
[ 13%] Built target em64t
[ 13%] Built target proc_gen-x8664
[ 13%] Built target targ_proc-x8664
[ 13%] Built target isa_pack_gen-x8664
[ 13%] Built target targ_isa_pack-x8664
[ 13%] Built target isa_bundle_gen-x8664
[ 13%] Built target targ_isa_bundle-x8664
[ 13%] Built target isa_decode_gen-x8664
[ 13%] Built target isa_hazards_gen-x8664
[ 13%] Built target isa_print_gen-x8664
[ 13%] Built target isa_pseudo_gen-x8664
[ 13%] Built target opteron_si_gen
[ 13%] Built target opteron
[ 13%] Built target proc_properties_gen-x8664
[ 13%] Built target sandy_si_gen
[ 13%] Built target sandy
[ 13%] Built target targ_abi_properties-x8664
[ 14%] Built target targ_isa_decode-x8664
[ 14%] Built target targ_isa_hazards-x8664
[ 14%] Built target targ_isa_print-x8664
[ 14%] Built target targ_isa_pseudo-x8664
[ 14%] Built target targ_proc_properties-x8664
[ 15%] Built target targinfo-x8664
[ 15%] Built target wolfdale_si_gen
[ 15%] Built target wolfdale
[ 15%] Built target comutil-host
[ 16%] Built target comutil-x8664
[ 16%] Built target gen_x_list
[ 16%] Built target gen_x_prop
[ 16%] Built target gen_x_set
[ 16%] Built target generate_preg_list
[ 16%] Built target generate_topcode
[ 18%] Built target wopt-x8664
[ 21%] Built target be-static-x8664
[ 24%] Built target cg-x8664
[ 24%] Built target be-exec-x8664
[ 26%] Built target be-x8664
[ 27%] Built target ipl-x8664
[ 29%] Built target lno-x8664
[ 30%] Built target wopt-shared-x8664
[ 31%] Built target whirl2c-x8664
[ 31%] Built target whirl2f-x8664
[ 32%] Built target prompf_anl-x8664
[ 32%] Built target headers-stage
[ 33%] Built target bfd
[ 33%] Built target ld
[ 33%] Built target stageit-ipa_link
[ 33%] Built target ipl-symlinks
[ 33%] Built target be-all
[ 33%] Built target wgen42-x8664
[ 34%] Built target inline-x8664
[ 35%] Built target ipa-x8664
[ 35%] Built target compiler-stage
[ 35%] Built target compiler-stage-C
[ 35%] Generating pscrt-static-x86_64/memcpy_em64t_c.o
Signal: Segmentation fault in Global Optimization -- LPRE: CO Var save/reload phase.
Error: Signal Segmentation fault in phase Global Optimization -- LPRE: CO Var save/reload -- processing aborted
*** Internal stack backtrace:
~/compiler/build/lib/4.0.10/x8664/be() [0x86c271]
~/compiler/build/lib/4.0.10/x8664/be() [0x86c970]
~/compiler/build/lib/4.0.10/x8664/be(ErrMsgLine+0x8e) [0x86c74e]
~/compiler/build/lib/4.0.10/x8664/be() [0x86de62]
/lib/x86_64-linux-gnu/libc.so.6(+0x33cc0) [0x2b65cd5adcc0]
~/compiler/build/lib/4.0.10/x8664/be(_ZN3CSE13Do_cse_pass_2Ev+0x808) [0x78a418]
~/compiler/build/lib/4.0.10/x8664/be(_ZN11EXP_WORKLST20Generate_save_reloadEP6ETABLE+0x60) [0x78a810]
~/compiler/build/lib/4.0.10/x8664/be(_ZN6ETABLE25Perform_LPRE_optimizationEv+0x3ed) [0x7f4ebd]
~/compiler/build/lib/4.0.10/x8664/be(_ZN9COMP_UNIT11Do_load_preEii+0xfb) [0x7f52db]
~/compiler/build/lib/4.0.10/x8664/be(Pre_Optimizer+0x29ce) [0x7f90de]
~/compiler/build/lib/4.0.10/x8664/be(Perform_Global_Optimization+0xaa) [0x85065a]
~/compiler/build/lib/4.0.10/x8664/be() [0x4a8022]
~/compiler/build/lib/4.0.10/x8664/be(main+0x748) [0x4a16b8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff) [0x2b65cd598e1f]
~/compiler/build/lib/4.0.10/x8664/be() [0x4a5e3d]
pathcc INTERNAL ERROR: ~/compiler/build/lib/4.0.10/x8664/be died due to signal 4
make[2]: *** [src/libpscrt/pscrt-static-x86_64/memcpy_em64t_c.o] Error 1
make[1]: *** [src/libpscrt/CMakeFiles/pscrt-static-x86_64.dir/all] Error 2
make: *** [all] Error 2
> Error: Signal Segmentation fault in phase Global Optimization -- LPRE:OMG! Bugz!
Вот зараза какая https://github.com/path64/compiler/issues/6#issuecomment-137...Release build with gcc isn't supported - Do a Debug build, but more
importantly gcc-4.2 is a *hard* dependency for building.Чем его ещо можна скомпилить если у него тажая жосткая зависимость к gcc-4.2 ?
Это подстегнёт разрабов GCC тоже шевелится быстрее. А обмен идеями и кодом тоже подстегнут развитие как GCC, так и EKOPath 4