на фтп к сожалению пока пусто, в том числе и master gnu


забыли про Graphite

+ поддержка новых процессоров

Intel Westmere
Intel Sandybridge с векторными расширениями AVX
AMD Bulldozer

и везде эт силви впереди планеты всей

Тебе что-то не нравится? По теме -- давно уже сижу на еженедельных снапшотах, заждался релиза.

packages :$ls -l gcc-4.4*
-rw-r--r-- 1 sylvia sylvia 10633559 2009-02-10 04:40 gcc-4.4.0-20090206-argenta.tar.lzma
-rw-r--r-- 1 sylvia sylvia 10636322 2009-02-15 20:06 gcc-4.4.0.20090213-argenta.tar.lzma
-rw-r--r-- 1 sylvia sylvia 10675613 2009-03-02 00:11 gcc-4.4.0-20090227-argenta.tar.lzma
-rw-r--r-- 1 sylvia sylvia 11477763 2009-03-19 00:51 gcc-4.4.0-20090313-argenta.tar.lzma

аналогично )

если нетерпеж берет , то можно не ждать ФТПшников , сбранчили уже 7 часов назад

svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch/

4.3.3 у меня сегфолтит на сборке мплеера.
а по теме - и че?

У меня срез от 20 марта, подожду релиза на фтп.

По теме у меня ни 4.3.3 ни 4.4.0 не сегфолтит, но последний ещё пока и не всё собирает.

последний собирает, кроме одного файла с asm , все остальное собирается и прекрасно работает )

для тех кто будет собирать

в 4.4.0 используется Graphite ( http://gcc.gnu.org/wiki/Graphite )

поэтому в зависимостях GCC помимо gmp, mpfr теперь также числятся
gmpxx (да, теперь GCC зависит от C++ и линкуется с libstdc++)
PPL (Pragma Polyedra Library)
CLooG (Chunky loop optimization)

в принципе GCC требует только gmp , mpfr, ppl (который требует gmpxx)
но крайне не рекомендуется собирать без CLooG, т.к. не будет бонуса оптимизации от Graphite, и в целом работать будет медленнее

ссылки на то что где брать есть в Graphite Wiki

~/tmp/gcc-4_4-branch/build :$gcc/xgcc --version
xgcc 4.4.0 20090328 (prerelease)

ай.. ждем ФТП вообщем ;)

Бенчмарки где нибудь есть?

А что они поломали?

> неопределенное поведение, связанное с незнанием некоторыми быдлокодерами понятия sequence points

Замечательно сказано :)

1. Сановский фортрановский код с директивами препроцессора поддерживается полностью или нет?

2. Там не ожидается ли нормальный 128-разрядный longdouble на интеле, а то сан в 30-й сборке цереры объявил -- только непонятно в связи с последними событиями, появится ли эта позарез нужная фича для широкой публики... :(

Прекрасно. Терпежу у меня хватает, поэтому жду в репозиториях Сида :)

>и на данный момент имеется всего лишь 76 незакрытых багов.

;(

радует, ждем в репо

А с оптимизацией как?

Пререлиз уже залили, gcc-4.4.

Хоть какая-то польза от FSF - разрабы лучше вылизали продукт.

PS А выкрикающие "гхе-це-це! гхавно! пианеры!! а вот у меня!!..." идут даже не лесом, а на х@й. gcc рулит!

> ещё пока и не всё собирает.

скорее не весь софт допилен для сборки им... в 4.4.0 убрали неявные инклуды cstdio и сделали более строгие проверки препроцессора, так что софт придётся пилить чтобы он собрался с 4.4.0, как когда-то пилили под 4.3.0, а не наоборот...

из имеющегося нового софта не собираются firefox3, inkscape, libicu, libntl, старые ветки Boost, а так же некоторые поделки kdegames из kde4.1 (или 4.2)...

firefox 3.0.8 я с утра собрала, но сегфолтится при запуске,
так что пришлось с 4.3.3 пересобирать все равно
у mozilla вообще с кодом нелады, попробуйте форсировать -O2 на всю сборку - сегфолтиться будет, оно с -Os собирается, отсюда кстати и частично тормоза...

(prerelease) - не Ъ

пусть исправят уже версию на 4.4.0 окончательно )

>А с оптимизацией как?

в целом код на С и С++ работает чуть быстрее чем тот же код собраный с теми же флагами оптимизации и GCC 4.3.3

ссылки на бенчмарки не приведу, тестировала с gzip , bzip2, lzma
в пределах 3-5% прироста

> понятия sequence points

чувствую себя быдлокодером.

Жаль, в ссылке http://gcc.gnu.org/c99status.html не появилось еще ничего о GCC 4.4, пока на соответствие стандарту С99 GCC полностью не соответствует, конечно все узкоспециализированно

http://www.google.ru/search?hl=ru&q=%D0%BF%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%...

первая ссылка на лор, хе-хе

> у mozilla вообще с кодом нелады, попробуйте форсировать -O2 на всю сборку - сегфолтиться будет, оно с -Os собирается, отсюда кстати и частично тормоза...

Обычно это все-таки глюки gcc, а не данной конкретной программы. А ядро тоже с -Os собирается. Потому что не слушали аналитиков ЛОРа.

В общем и целом, наезд на мозиллу и их код непонятен. Нормально у них всё.

> В общем и целом, наезд на мозиллу и их код непонятен. Нормально у них всё.

Наезжают те, у кого код "лучше" :-)

ядро с -Os (равно как и любой другой софт) собирается опционально
оно и с -O2 может собираться настолько же успешно
(опция Optimize for size в menuconfig)

а вот мозилла с -O2 собирается, но будет падать, соберите - узнаете сами

>глюки gcc

4.2
соберите Icc - еще хуже будет.
Всех версий чтоли? почему у других все нормально ?

>> понятия sequence points

> чувствую себя быдлокодером.

Дайте кто-нить ссылочку простому быдлокодеру где про понятие sequence points можно прочитать, желательно по-русски. Спасибо.

Например, в блоге всем извесной девушки :) hint -> Алёна C++

> Дайте кто-нить ссылочку простому быдлокодеру где про понятие sequence points можно прочитать

Например, ISO/IEC 9899:1999 глава 6.5

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

> желательно по-русски. Спасибо.

Программист на Си _обязан_ понимать технический английский. No ifs, buts, or maybes about it.

> забыли про Graphite

Я на него и намекал, когда писал про оптимизацию циклов :)

а чем же она известна?

> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

спасибо

> а чем же она известна?

Хмммм, если вопрос не праздный, то после внимательного просмотра блога все станет понятно :)

Ядро с -Os собирается по дефолту. Это было про шпильку о том, что из-за -Os тормоза.

Про глюки с оптимизациями -- бывает такое, что с -Oчто-то для чего-то генерируется неправильный код. У меня такое, например, было -- сравнительно несложная итерация по какому-то контейнеру с -O3 не работала, а с -O2 работала. В плюсовом софте соответственно такое чаще может возникнуть, в силу волосатости самого языка. Это не значит, что код "плохой". Но только один stl там может развернуться в процессе компиляции в сложную мешанину. Можно переписать ту часть, которая ломается оптимизатором, попроще. Можно просто выключить для этого участка оптимизации. Лично мое мнение состоит в том, что оптимизировать все те 99% кода, который выполняется 1% времени, просто не стоит. Гарантия безглючности и корректность отладки важнее и полезнее. Сейчас как раз в gcc появилась возможность указывать уровень оптимизации для каждой функции отдельно, что позитивно.

Спорить не хочу на эту тему. Кто-то делает, а кто-то ругает. Лагерь вторых мне неинтересен абсолютно.

> Опция -Wsequence-points теперь работает внутри условий if/while/for, и позволяет легко обнаружить неопределенное поведение, связанное с незнанием некоторыми быдлокодерами понятия sequence points

/me быдлокодер. (

А скорость померяла между 4.3.3 или 4.4.0 ??? Или опять забыла про комманду time :)

> Ядро с -Os собирается по дефолту.

Нет. Дело давнее, историю про -Os я уже не помню, если честно, но современное ядро в основном с -O2, и, насколько я помню, для некоторых файлов особые флаги, именно для обхода неправильной генерации кода гцц. Впрочем, давно не следил, могу уже ошибаться.

если вам нужна разница в скорости сборки самим GCC...

core2 2.0 Ghz
make -j1

1 SBU / GCC 4.4.0- 20090313
real 2m31.701s
user 2m2.349s
sys 0m23.108s


1 SBU / GCC 4.3.3
real 1m50.255s
user 1m22.115s
sys 0m22.799s

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

Отличная новость.

оффтопик - кто-нибудь сталкивался с VC++, как по скорости кода в сравнении с последними GCC?

>оффтопик - кто-нибудь сталкивался с VC++, как по скорости кода в сравнении с последними GCC?

На этом сайте как-то ссылку давал на форум на сайте микрософта месяц назад, про сравнение mingw 4.3 и vc++. По дефолту mingw рвёт vc++ в два(!) раза. Но это без оптимизаций.

ну и раз такие дела то

1 SBU для

GCC 4.2.4
real 1m57.221s
user 1m28.904s
sys 0m23.015s

GCC 4.1.2
real 1m46.541s
user 1m18.792s
sys 0m22.555s


GCC 3.4.6
real 1m41.131s
user 1m13.269s
sys 0m22.092s

ps:
если кто не в курсе
SBU - standard build unit , в терминологии LFS - время сборки пакета binutils

pps: GCC у меня немного "на стероидах" так что если кто будет тестировать на аналогичной конфигурации и получит результаты с дольшим временем компиляции... ну это майнтейнеры ваших дистров так собрали. Особенно медленный GCC в Дебиане 32 бит (из за bi-arch поддержки)

> Но это без оптимизаций.

А с оптимизациями? ;)

Если кого-то волнует время сборки, то логично сравнивать с -O0 (чтобы сборка была действительно быстрая). А у тебя какие опции?

>А с оптимизациями? ;)

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

>логично сравнивать с -O0 (чтобы сборка была действительно быстрая)

сферический тест получится, Вы постоянно собираете с -О0 ?

тестировала реальный SBU с реальными опциями

-O2 -fomit-frame-pointer -march=pentium4


march задала потому что ранние компиляторы имеют чуть другие умолчания у меня,
а так - все одинаково

> но ты можешь сам попробовать

У меня не установлена венда, и нет вижуальника.

> Там было предположение, что с оптимизациями они будут равны в рамках погрешности или с минимальным превосходством vc++

Очень сильно сомневаюсь. Думаю, что код из-под vc может быть заметно быстрее. Потому и хотелось бы знать результаты тестов.