LINUX.ORG.RU

Официальный релиз набора компиляторов GCC 4.4.0

 , ,


0

0

Вышел набор компиляторов GCC 4.4.0 с измененным лицензионным соглашением на runtime - «GCC RUNTIME LIBRARY EXCEPTION», убирающим некоторые ограничения лицензии GPLv3 для Runtime компонент набора компиляторов, что позволяет генерировать в GCC любой код, независимо от лицензии под которой он будет распространяться (например, в качестве runtime теперь можно использовать код для обеспечения работы виртуальных машин, обрабатывающих байткод, в том числе Java).

Основные изменения по сравнению с веткой GCC 4.3.x:

  • Добавлен оптимизатор Graphite, основанный на полиэдральном промежуточном представлении - технологии оптимизации для обеспечения параллельного выполнения циклических операций. Оптимизация касается всех языков, поддерживаемых GCC. Разработка позволяет значительно увеличить производительность обычных приложений на многоядерных процессорах, созданных без использования специальных библиотек распараллеливания, например, Threading Building Blocks.
  • Добавлены новый аллокатор регистров (IRA - integrated register allocator) и новый планировщик расстановки инструкций.
  • Новые опции оптимизации: "-findirect-inlining", "-ftree-switch-conversion", "-ftree-builtin-call-dce" и "-fconserve-stack";
  • Новые опции предупреждения о потенциальных ошибках в коде: "-Wparentheses", "-Wsequence-points", "-Wconversion", "-Wuninitialized" и т.д.
  • Реализована поддержка версии 3 спецификации OpenMP (API для параллельных вычислений);
  • Улучшена поддержка грядущего С++ стандарта C++0x, например, в libstdc++ добавлены заголовочные файлы chrono, condition_variable, cstdatomic, forward_list, initializer_list, mutex, ratio, system_error и thread;
  • Произошли множественные изменения в поддержке языков C/C++/Fortran;
  • Улучшена поддержка уже поддерживаемых архитектур: добавлены средства оптимизации для CPU ARM Cortex-A9, Cortex-R4 и Cortex-R4F, PowerPC e300c2, e300c3, e500mc, IBM System z10 EC/BC; добавлена поддержка встроенных функций Intel AES, Intel PCLMUL, Intel AVX; улучшена поддержка архитектур MIPS, AVR, IA-32/x86-64, IA-32/IA64, PowerPC и т.д.
  • GCC стал считать ошибками некоторые программисткие «решения», который компилировались ранее. Например, теперь не работает «#elif» без аргумента; «cstdio» больше не подразумевает включение «string.h», «ios.h», «iomanip.h», «streambuf.h» и «locale.h», а «stdint.h» не включает «string.h» и «ios.h». ; строковые функции больше не принимают «char*» вместо «const char*»; ужесточены требования к инициализации C++ классов.

Разработчики Fedora уже ранее заявили о том, что версия 11 дистрибутива будет полностью скомпилирована GCC 4.4.0. Однако, работа предстоит немалая: при попытке пересборки новым компилятором 6228 пакетов дистрибутива было зафиксировано 559 ошибок.

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



Проверено: hibou ()

копипаста с опеннета.. фу

ну и новость уже была, просто сейчас наконец-то убрали (prerelease)
и выложили tarball на ftp

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

> копипаста с опеннета.. фу

Да уж куда им до нашей машины времени :)

Manhunt ★★★★★
()

Ужесточение требований к коду и нвые ворнинги это здорово, но "строковые функции больше не принимают "char*" вместо "const char* " - бгг =)

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

Интересно как это отразится на скорости работы программ после компиляции... :) Мне, как пользователю Gentoo этот вопрос очень интересен. =)

Shalakhin
()

OMFG!!! Суперновость :)

Spectr ★★★
()

>Однако, работа предстоит немалая: при попытке пересборки новым компилятором 6228 пакетов дистрибутива было зафиксировано 559 ошибок.

А ведро-то хоть соберет?

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

> Почти, потому что в прошлый раз не было официальных тарболлов =).

Старая новость была ложной - релиза не было. Кроме этого, после той новости было не мало коммитов.

tempuser001
() автор топика
Ответ на: комментарий от goose

> Да мне тоже интересно. Такой код: void f(char* input) { char buf[12]; strncpy(buf, input,11); .... } Теперь не компилируется?

Получается что не скомпилируется, хотя причин не допускать неявное преобразование char * в const char * не вижу.

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

Переводчики - некомпетентные идиоты:
http://gcc.gnu.org/gcc-4.4/porting_to.html

An example.

#include <cstring>

const char* str1;
char* str2 = strchr(str1, 'a');

Gives the following compiler error:

error: invalid conversion from ‘const char*’ to ‘char*’

Fixing this is easy, as demonstrated below.

#include <cstring>

const char* str1;
const char* str2 = strchr(str1, 'a');

ip1981 ☆☆
()
Ответ на: комментарий от Sylvia

>wine компилить давно можно, но работает оно нестабильно

>лучше 4.3.3

Вроде как MS ABI появилось только в 4.4

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

> layman -a gcc-porting

Спасибо, но gcc-4.4.0_pre9999.ebuild - это SVN. Хотелось бы ебилд для релиза, хотя он даже в ~arch в Gentoo попадет не скоро.. =\

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

там релиз сейчас в SVN лежит

branch 4.4 это релиз, по крайней мере сегодня

завтра могут уже таг поставить что 4.4.1 prerelease

Sylvia ★★★★★
()

круто! уже собираю, позже попробую ядро собрать + парочку программок.

NegatiV
()

хорошие новости - ядро и модули собрались. так же собрался Valknut и Transmission. Qt компилить не пробовал - нету времени. В общем, думаю сделать его компилятором по-умолчанию =)

P.S. размеры некоторых бинарников, собранных с помощью gcc-4.4.0 меньше на 2-3% от размера того же бинарника, но собранного с gcc-4.3.0, но компилится, на мой взгляд, чуть дольше (не замерял, так что оценка субъективна)

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

ну а time'омом какие нить операции распаковки или кодирование если замерить?

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

> Когда-же MinGW переведут на 4-ую ветку GCC???

Я наверное чего-то не догоняю, но на официальном сайте есть альфа 4.3 включительно. Сам собираю кросс из Ubuntu с mingw GCC 4.3.3 (QT4.5 приложение - либы ставил под wine официальной сборки) - всё отлично работает, проблем не замечал (и в wine, и в Vista).

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

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

проблемы есть с
- mozilla
- wine (нестабильно работают программы windows)
- mplayer (не может собрать один из ассемблерных файлов, странно что до сих пор пока не исправили)

сравнение скорости компиляции
http://www.linux.org.ru/jump-message.jsp?msgid=3591941&cid=3592665

небольшая проверка производительности кода на С
http://www.linux.org.ru/jump-message.jsp?msgid=3591941&cid=3592695

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

У меня ядро, модули и весь world в генте собран gcc 4.4_pre9999 (aka SVN) с просто извратными флагами. В итоге все без проблем работает.

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

увы, тенденция, к сожалению, налицо ...
хотя например если сравнить ветку gcc 2.x (если точнее, то я брала egcs 1.1.2)
то там скорость хуже чем с 4.4 , ну и не сравнивала 4.0 и другие 3.x (только 3.4 ветку)

с другой стороны для таких процессоров как Sandybridge с расширениями векторизации AVX GCC 4.4 и возможности Graphite как раз нужны )

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

Мне вот сильно интересно, как gcc использует кеш процессора..
Потому что после смены проца с celeron 520 на core2 T5600 все просто летало. Но как только пересобрал world, начались тормоза.

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

1 SBU/ Core2 2.0 Ghz / make -j1
CFLAGS='-O2 -pipe -march=pentium4 -mfpmath=sse -g0 -fomit-frame-pointer'
4.3.4 (pre) vs 4.4.0 (release)
оба компилятора были собраны с PGO, то есть если сравнить с тем , что я намерила с GCC от 13 марта, то либо улучшили производительность, либо 4.4 более улучшенно собирает сам себя с использованием PGO

real 1m50.005s
user 1m16.758s
sys 0m26.058s

4.4:
real 1m49.795s
user 1m17.198s
sys 0m26.188s

--------- Gzip (без asm) performance 512 Mb urandom data ----------
4.3.4
34.87user 0.17system 0:35.41elapsed 98%CPU
4.4.0
33.71user 0.18system 0:34.30elapsed 98%CPU

похоже доработали производительность за месяц )

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

Хм... Интересно, интересно.. В любом случае, я вчера ночью gcc пересобрал.
Ничего из флагов компиляции не посоветуешь для x86_64?
Тут поковырял немного Криса Касперски, он много чего советует, но хотелось бы спросить еще кого-нибудь знающего.

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

icc... Мечта для числодробилок.. Но, думаю, и gcc можно так флагами настроить.

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

>увы, тенденция, к сожалению, налицо ... >хотя например если сравнить ветку gcc 2.x (если точнее, то я брала egcs 1.1.2) >то там скорость хуже чем с 4.4 , ну и не сравнивала 4.0 и другие 3.x (только 3.4 ветку) >с другой стороны для таких процессоров как Sandybridge с расширениями векторизации AVX GCC 4.4 и возможности Graphite как раз нужны )

Иногда, находясь рядом с Silvy, я чувствую себя неполноценным.

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

ну со вчерашнего дня там наверное поменяли только changelogs
и убрали слово prerelease из /gcc/DEV-PHASE

с флагами не посоветую ) но world лучше не бросаться собирать без надобности,
лучше для начала проверить на кош^W какой-нибудь мелочи вроде gzip

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

-O2 -msahf -march=core2 -mmmx -mssse3 -ftree-vectorize -fomit-frame-pointer -pipe

для core2 (conroe) 64bit , а больше наверное ничего существенного не придумать

только для -msahf лучше посмотреть чтобы было lahf_lm в /proc/cpuinfo flags

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

>лучше для начала проверить на кош^W какой-нибудь мелочи вроде gzip
Это естественно. К сожалению, per package cflags в генте будут еще не скоро :( а так хочется совершенства..

>с ядрами я тоже предпочитаю не рисковать, хотя бы по тому что вайн выдает кучу ошибок в приложениях

Ядро работает стабильно абсолютно. Wine мне особо не нужен, там более на amd64 у него проблем многовато.

>-O2 -msahf -march=core2 -mmmx -mssse3 -ftree-vectorize -fomit-frame-pointer -pipe

Свои я показывать боюсь) там очень много наворочено с разворотами циклов, ftracer, отключением выравнивания инструкций.
Кстати, а почему core2, а не native? да и fomit-frame-pointer включается автоматом, насколько я это в мане увидел.

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

>Это естественно. К сожалению, per package cflags в генте будут еще не скоро :( а так хочется совершенства
эээ О_о
$ cat /etc/portage/package.cflags
#dev-db/mysql -DPIC -fPIC

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

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

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

per package cflags в генте будут еще не скоро

./configure && make
опционально make install DESTDIR=

тот же gzip можно даже не инсталлировать )

>Ядро работает стабильно абсолютно

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

>много наворочено с разворотами циклов, ftracer, отключением выравнивания инструкций.


обычно все это включается в -O2 / -O3 и т п, в генту вики хорошо написано что включено , а что нет.

>почему core2, а не native?

предпочитаю явно задавать -march и -mmmx -msse*
если что gcc <Ваши флаги> -Q --help=target
может показать немного неожиданые вещи..

>да и fomit-frame-pointer включается автоматом

на тех архитектурах , которые поддерживают отладку без frame pointer
ia32 / x86_64 к таковым не относится



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

>обычно все это включается в -O2 / -O3

Как раз добавлено то, что не включено даже в -O3
Насчет вики - в манах написано больше.

>тот же gzip можно даже не инсталлировать )

собрать бы систему с PGO, но вот не получится же)

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

ps: Gentoo-way конечно хорошо, но все эти оптимизации много не дают в итоге (5-10%) для 64 бит я бы вообще ничего не пересобирала, там итак почти все хорошо, в любом дистрибутиве.
Gentoo 64 хороша еще и тем , что более гибко управляются зависимости пакетов.

но меня и слака из дебиана вполне устраивает,к тому же пока у меня ia32 и собираю я с -march=pentium4 , для ноута.

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

LFS можно собрать с PGO

но времени уйдет на это прилично ) ну и выигрыш будет суммарный 10-15% )
с PGO хорошо собирать те вещи , которые либо постоянно, либо периодически кушают процессор

Xorg server хорошо бы , у меня пока просто icc собран на десктопе, а на ноуте так вообще дистрибутивный пока зависимости не утряслись squeeze-sid
conky
архиваторы , особенно lzma , p7zip
gcc (его вообще просто, но PGO там GCCшное, оно похуже ICC, но все равно лучше чем ничего)
наверное все, больше не вижу кандидатов )
может mplayer и кодировщики видео, для тех кто с этим работает, хотя там все тяжелое уже переписали на asm

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