LINUX.ORG.RU

25 лет GCC и выпуск 4.7.0

 , ,


0

3

Состоялся выпуск GCC версии 4.7.0, приуроченный к 25-летней годовщине проекта.

Основные изменения в этой версии:

  • Поддержка транзакционной памяти на некоторых архитектурах.
  • Расширена поддержка C++11, включая атомарные операции и модель памяти.
  • OpenMP 3.1.
  • Улучшение оптимизации во время компоновки (Link Time Optimization).
  • Новые расширения для отладки кода.
  • Добавлена поддержка архитектур Adapteva's Epiphany, National Semiconductor's CR16, TI's C6X, Tilera's TILE-Gx и TILEPro.
  • Поддержка Intel Haswell и AMD Piledriver; Cortex-A7 (ARM).

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 1)
Ответ на: комментарий от Vudod

имелось ввиду «скорее проц, чем оперативка»

что до графики, на видео хватает вполне (ибо не fullhd же на нетбуке смотреть).

и вообще, мы сейчас про драйвера для линукса говорим?

MyTrooName ★★★★★
()

Получается, техасовские DSP теперь в gcc и левые закрытые тулчейны больше не нужны?

slapin ★★★★★
()

Ну наконец-то! Таки. Сделали. Это.

Не забудь упомянуть про то, что теперь стадии 2-3 собираются с g++ только и про улучшения в genautomata для не хэ86.

powerpc
()
Ответ на: комментарий от buddhist

Паскаль же

Мне нравится Паскаль, но у него слабая инфраструктура, по сравнению с Си, и за ним уже нет никого сильного, как за Го. Т. е. будущего у него скорее всего нет, а у Го, возможно, есть.

К тому же, насколько я знаю, в нем нет ни встроенной многопоточности, ни вывода типов, ни возможностей ФП.

unsigned ★★★★
()
Ответ на: комментарий от unsigned

Есть Ада, у которой сильная инфраструктура и за которой стоят серьезные люди :)

возможностей ФП

Поверьте лисперу, они не нужны.

buddhist ★★★★★
()
Ответ на: комментарий от buddhist

Если ФП это про функциональное программирование - то не верю, нужно оно как и логическое - возникли они не вчера, а даже задолго до новомодных языков и проживут еще долго в отличии от модных ныне, и за функциональным и логическим программированием наше светлое будущее (я про программистов).

Сейчас скомпилировал под Gentoo gcc-4.7.0 через таким же образом подготовленный и собранный как и месяц назад ebuild для gcc-4.6.3. Ebuild-ы готовил сам (готовых просто не нашел) на основе пачтей для gcc-4.6.2 и нового pie 0.5.2 для 4.7.0. Остальные патчи взял от 4.6.2, но пришлось примерно 10 патчей поправить для 4.7.0 (для 4.6.3 не больше пяти правил).

Сейчас произвожу пробную сборку mc, imagemagick, inkscape.

Если все удачно, то затем сборка ядра 3.3.0 и затем уже попытка сборки glibc-2.15.

Deleted
()
Ответ на: комментарий от Deleted

Если ФП это про функциональное программирование - то не верю, нужно оно как и логическое

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

buddhist ★★★★★
()
Ответ на: комментарий от buddhist

Лично я не против фич ФП и ЛП в новомодных языках. Глядишь поклонники этих языков начнут чаще использовать ФП и ЛП в своей работе и учебе, а то и вовсе переключатся на правильные языки.

Все о чем писал ранее успешно пересобралось на gcc-4.7.0. Решил теперь собрать nginx-1.1.17. Не получилось - обломилось на boost-1.4.8. Итак, обновление споткнулось на boost. Не захотел он собираться на gcc-4.7.0. Сейчас разбираюсь, ищу информацию как обойти трабл:

«x86_64-pc-linux-gnu-g++» -ftemplate-depth-128 -march=amdfam10 -O2 -pipe -finline-functions -Wno-inline -w -pthread -fPIC -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o «bin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi/cpplexer/re2clex/cpp_re.o» «libs/wave/src/cpplexer/re2clex/cpp_re.cpp»

...skipped <pbin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_wave-mt-1_48.so.1.48.0 for lack of <pbin.v2/libs/thread/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_thread-mt-1_48.so.1.48.0... ...skipped <pstage/lib>libboost_wave-mt-1_48.so.1.48.0 for lack of <pbin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi>libboost_wave-mt-1_48.so.1.48.0... ...skipped <pstage/lib>libboost_wave-mt-1_48.so for lack of <pstage/lib>libboost_wave-mt-1_48.so.1.48.0... ...failed updating 9 targets... * ERROR: dev-libs/boost-1.48.0-r1 failed (compile phase): * Building of Boost libraries failed

Deleted
()
Ответ на: комментарий от Deleted

nginx не собрался из-за passenger который уперся в boost.

boost успешно обновил до 1.49.0 (правкой штатного ebuild 1.48.0), но и после этого nginx+passenger не собираются.

Думаю все проблемы в несовместимости passenger с gcc-4.7.0 и boost. В поисках решения.

Deleted
()
Ответ на: комментарий от Deleted

вовсе переключатся на правильные языки

Переключиться на «правильные» языки полностью нельзя в силу врожденной тормознутости большинства ФП-фич.

buddhist ★★★★★
()
Ответ на: комментарий от Deleted

Этот патч примененный к файлу boost из passenger-a решил проблему сборки nginx-1.1.17 под gcc-4.7.0.

https://svn.boost.org/trac/boost/changeset/76133/trunk/boost/config/stdlib/li...

Теперь очередь за cuda-sdk.

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

Deleted
()
Ответ на: комментарий от Deleted

CUDA SDK 4.1 ранее успешно собиравшийся на gcc-4.6.3 boost-1.48.0 glibc-2.15 на отрез отказывается собираться на gcc-4.7.0 boost-1.49.0 glibc-2.15 - готового решения пока не нашел, если кто уже собрал отпишитесь пожалуйста:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4/ext/atomicity.h(48): error: identifier «__atomic_fetch_add» is undefined

/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/include/g++-v4/ext/atomicity.h(52): error: identifier «__atomic_fetch_add» is undefined

Других проблем после перехода на gcc-4.7.0 не выявлено.

Deleted
()
Ответ на: комментарий от Deleted

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

это теория или уже проверено на опыте?

была у меня мыслишка дать деткам, незнакомым с программированием почти вообще, хаскель, вместо традиционно паскаля/цпп, и посмотреть результат. но не позволили (:

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

Так думает автор учебников по Haskell Душкин. Я тоже разделяю эту точку зрения. Деткам нужно давать ФП и ЛП, вместо того что не дает прорывных результатов, а дает только вяло текущее исправление трудно отлавливаемых багов и как результат - короткий (не более 3 лет) жизненный цикл изделий и как следствие не удовлетворенность результатами своего труда, который в основном идет на корзину, а не на пользу.

Deleted
()

народ салют!

Почитав комменты, что-то не уловил. Нужен нам Gcc или уже можно переходить на Clang?

/* Рад, что вышла новая версия. Вскоре пойду тестить =) */

muteki_okami
()
Ответ на: народ салют! от muteki_okami

too fat

gcc нужен. переходить на clang тоже можно.

clang не навязывает GPL-лицензию, компилит быстро, но пока не все gcc-фишки умеет. плюс - информативные сообщения об ошибках, llvm и все его бонусы

gcc умеет все gcc-фишки (внезапно, да), чуть лучше оптимизирует код, умеет больше языков/платформ.

еще gcc внезапно ломает компилируемость различных пакетов при своих минорных апдейтах. по clang'у информации об этом у меня нет

MyTrooName ★★★★★
()
Ответ на: комментарий от Deleted

http://forums.nvidia.com/index.php?showtopic=106592&st=0&p=590552&amp...

Проблема с CUDA SDK 2009 года наблюдается снова. Решение простое - добавить в cu файл (или еще лучше в один из заголовочных файлов #undef _GLIBCXX_ATOMIC_BUILTINS

и теперь примеры CUDA SDK 4.1 успешно собираются и на GCC 4.7.0

Deleted
()
Ответ на: комментарий от MyTrooName

А если не секрет

То, каким именно компилятором компилят крупные конторы свои проекты? Интересны проекты под Linux конечно.

muteki_okami
()
Ответ на: А если не секрет от muteki_okami

к крупным конторам отношения не имею)

скорее всего, 99% контор юзают gcc, ибо linux исторически спарен с GNU. но в последнее время появляются намеки на возможность перемен.

вот тут можно вычленить порядочно любопытного по теме: Debian: clang способен заменить gcc

MyTrooName ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

поищите во всяких гитхабах и сорсфорджах по фильтру «язык:ассемблер», там вроде везде есть такая возможность

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

MyTrooName ★★★★★
()
Ответ на: комментарий от buddhist

Лично я вижу место Go в серверной среде. Немалую роль тут играет заточенность его референсного компилятора на amd64. Сейчас у него еще слишком много детских проблем(многие из которых решаются разработчиками достаточно быстро).
Основные идеи мне очень близки (особенно реализация «многопоточности» и ipc между «потоками» сразу в языке). Писать на нем просто и главное нет этих новомодных заигрываний с ФП. Как я думаю - Go это, чем мог стать D.
Если интересно - можно почитать их рассылку https://groups.google.com/forum/?fromgroups#!forum/golang-nuts

kodx
()
Ответ на: комментарий от kodx

Не понял чем Go лучше Си, Си++ или того же Паскаля. Чем Вам лично не угодило «новомодное» ФП (Haskell развивается не меньше времени, а главное быстрее чем Си++, и быстрее других впитывает в себя все полезное из новомодных возможностей императивного программирования но на декларативный манер)? По моему место Go конкурировать с Си++, и даже не с системным Си. И до возможностей предоставлящих ФП, обычным традиционным языкам, не дотянутся даже при наличии фич ФП в них.

Deleted
()
Ответ на: комментарий от Deleted

Я тоже считаю, что Go сможет когда-нибудь конкурировать в нише, в которой сейчас C++ и иногда даже Java (серверный или системный софт).
Чем он лучше Си, С++:
- синтаксический сахар - самое главное - не нужно ставить точку с запятой после каждой строки, ИМХО это просто киллер фича, сколько было проблем с тем, что где-то забыл поставить эту точку с запятой и компиляция вываливалась в совершенно другом месте, определение типа при создании переменной без его явного указания(хотя можно и указывать), короче много мелких вещей на которые уходит время и повышается вероятность совершить ошибку, да и для новичков хорошо - не нужно забивать этим голову, о отсюда лаконичность самого кода;
- встроенная «многопоточность» с ipc - больше никаких pthreads, все что нужно сразу заложено в языке, сейчас это становится все более актуальным, т.к. почти все компьютеры имеют по несколько ядер;
- концепция интерфейсов - это не ООП и не шаблоны, а что-то среднее;
- работа с юникодом и юнокодовыми строками из коробки;

Обычно я представляю себе Go как некий симбиоз Си и Питона, из си мы имеем комплируемый код, а из питона - синтаксический сахар и простоту написания.

По поводу ФП - лично для мне его эталоном является Lisp, это что-то с невозможным синтаксисом (примерно как брейнфак). Как я думаю всем этим языкам место в учебных заведениях или может в каких-то задачах, где одна только математика.
Может быть я такой прожженный императивщик или пробитый ретроград, но мне лично тяжело читать вот такой код(взято отсюда http://ru.wikipedia.org/wiki/Haskell , хотя первый раз вижу код на Haskell):
primesST = 2 : 3 : sieve 0 5 9 (drop 2 primesST)
where
sieve k x q ps = let fs = take k (tail primesST) in
[n | n <- [x,x+2..q-2], all ((/=0).rem n) fs]
++ sieve (k+1) (q+2) (head ps^2) (tail ps)

а это выливается в трудности его дальнейшей поддержки.

Большинство ФП языков - интерпретируемые, а значит делать приложения, которые работают 24/7 на этом невыгодно (слишком много ресурсов будет нужно). Если уж так нужен интерпретируемый язык - то есть баш или на крайний случай питон.

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

kodx
()
Ответ на: комментарий от kodx

хотя какие-то упоротые написали на haskell оконный менеджер

на haskell чего только не написано. система управления версиями, de-шка даже есть какая-то, и ничего. упомянутым оконным менеджером пользуюсь сам, лично. все время пытаюсь найти его аналог на с, но в каждом варианте чего-то да не хватало существенно.

но мне лично тяжело читать вот такой код

когда я вообще не знал С, мне тоже было трудно читать код хелловорд.ц

в приведенном вами фрагменте нет ничего сложного, если его правильно отформатировать и знать синтаксис языка

MyTrooName ★★★★★
()
Ответ на: комментарий от kodx

Большинство ФП языков - интерпретируемые

может, и больше половины, но не существенно.

а вот среди популярных императивных/объектно-ориентированных языков: c/c++, java, python, ruby, php - какова доля компилируемых? из перечисленных только с/c++, поправьте, если что-то *популярное* пропустил

MyTrooName ★★★★★
()
Ответ на: комментарий от kodx

Все верно, но прогнозы относительно языков из числа Haskell, Рефал, Акторный Пролог - очень хорошие. Возможно именно они или их наследники приблизят момент появления умной машины и программы с элементами очень похожими на уже забытый ИИ. Haskell и Prolog используют (не предавая это широкой огласке) на промышленном уровне во всех областях. Многие задачи очень изящно решаются с помощью математически прозначного кода в десяки раз более короткого и в разы быстрее выполняющегося чем на Си++ (при условии что на Си++ задача реализуема достаточно оптимально). Haskell в основом используется в компиляторах. Пролог можно использовать как продвинутую замену невнятным языкам запросов, способным выдавать в качестве результата только колонки и строки, Пролог же может выдавать также и связанные тексты и позволяет делать заключения на основе хранящейся информации.

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

У ФП и ЛП языки идут в ногу с развитием теории и появлением потребности в новых возможностях у прикладников.

Deleted
()
Ответ на: комментарий от MyTrooName

Чтобы узнать что написано на Haskell достаточно зайти на страничку проекта. Его к примеру с успехом применяют для веб-разработки (по типу Ruby On Rails), а также для утилизации возможностей многоядерных платформ (к примеру той же Cuda через ffi), а Акторный Пролог ориентирован на встроенное в него распараллеливание.

Нет Си конечно тоже нужен (на нем ядро Linux наиисано), и много интересных идей появилось и в Си++, и в Ruby, но всех эти идеи успешно поглощают языки ФП и даже прелагают более изящные и значительно более производительные решения (к примеру фирменная фича ROR - Haml, полная копия в Haskell - Hamlet, а тажке более продвинутое решение - blaze-html).

Deleted
()
Ответ на: комментарий от Deleted

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

MyTrooName ★★★★★
()
Ответ на: комментарий от kodx

primesST = 2 : 3 : sieve 0 5 9 (drop 2 primesST) where sieve k x q ps = let fs = take k (tail primesST) in [n | n <- [x,x+2..q-2], all ((/=0).rem n) fs] ++ sieve (k+1) (q+2) (head ps^2) (tail ps)

Это всего лишь пример и даже не из реальной жизни, причем очень неудачный и с целью запугать непосвященных в основы ФП.

На Си и Си++ гораздо легче привести более запутанный а зачастую даже и абсудрный код (который потом выправляют и оптимизируют целую вечность) - для примера можно взять фрагмент из кода для какого нибудь драйвера или модуля.

Deleted
()
Ответ на: комментарий от Deleted

Приводя этот код, я имел в виду, что далеко не всегда нужно использовать лямда-выражения, потому как они запутывают код. Может быть это выглядит красиво, когда одна строчка делает столько всего полезного, но когда вам через 4 года придется вернуться к этом коду, то понять его сразу будет тяжело, даже если его писали вы сами.
Можно почитать Эрика Реймонда, в его книге «Искусство программирования для UNIX» про это хорошо написано.

kodx
()
Ответ на: комментарий от kodx

ФП требует математической подготовки, потому ФП неприменим для написания того, что сейчас принято называть коммерческим кодом. Но от отказа от ФП код не становится понятнее, скорее напротив. Тяжело читать любой императивный код, который сами не писали, а ФП более унифицированный, зная шаблонные алгоритмы и способы их реализации при ФП, труда в чтении кода не будет, тем более при наличии ключевых комментариев, хотя бы по одной строке комментария на 100 строчек кода. Также хотелось бы отметить что алгоритм на языке функционального прораммирования в среднем в десять раз короче кода на императивном языке. Конечно есть алгоритмы которые больше или меньше подходят для ФП и ЛП, но в последнее время были разработаны приемы, позволяющие облегчить реализацию и таких алгоритмов применяя только методы ФП и ЛП.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.