GCC 4.1.2

Этот баг так и не исправили: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290

а жаль =)

С недоверием относился к четвертой ветке, когда она еще была нестабильной, сейчас все стабилизировалось, но "осадок остался". ;)
Сейчас пользуюсь GCC 3.4.6. Стоит ли переходить на новую ветку?

>Стоит ли переходить на новую ветку?

Если новое не нужно, то не стоит переходить на новый софт. Я лично на gcc-4 потому, что он поддерживает новые флаги для g++

Чисто багфикс, ничего сверхинтересного.

Баян, ебилды ещё вчера в обед свалились.

с -Os компилит намного быстрее и код более быстрый

простите
может я не ту траву курю...
но сейчас у меня собирается gcc-4.3-20070209, и тут я узнаю что наконец вышла версия 4.1.2...
приятно конечно...
но непонятно :-)

>но сейчас у меня собирается gcc-4.3-20070209, и тут я узнаю что наконец вышла версия 4.1.2...

Угу... А в openSUSE 10.2 - gcc-4.1.3...

>но сейчас у меня собирается gcc-4.3-20070209, и тут я узнаю что наконец вышла версия 4.1.2... приятно конечно... но непонятно :-)

А что непонятного? svn от 9 февраля 2007 года.

>С недоверием относился к четвертой ветке, когда она еще была нестабильной, сейчас все стабилизировалось, но "осадок остался". ;) Сейчас пользуюсь GCC 3.4.6. Стоит ли переходить на новую ветку?

в трешке нет флага -ftree-vectorize (кстати, он почему-то и в 4-ке по умолчанию не включается в -O3), а амд-шники рекомендуют его включать ( http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32035... )

не... то что от 9-го февраля это понятно...
но у меня 4.3 ветка стоит...
выходит новость про выход ветки 4.1 - это баян?

>но у меня 4.3 ветка стоит...

Это которая stage1?

и зачем она тебе? ты один из разработчиков/тестеров ГЦЦ или перед девочками вмето пиписьки этим красуешься?

А что лучше по производительности GCC 4.x или Intel compiler?

[I] sys-devel/gcc
     Available versions:  
        (2.95)  [P]2.95.3-r9 [P]~2.95.3-r10
        (3.1)   [P]3.1.1-r2
        (3.2)   [P]*3.2.2 [P]3.2.3-r4
        (3.3)   [P]3.3.2-r7 3.3.5-r1 3.3.5.20050130-r1 3.3.6 3.3.6-r1
        (3.4)   ~3.4.1-r3 3.4.4-r1 3.4.5 3.4.5-r1 ~3.4.6 3.4.6-r1 3.4.6-r2
        (4.0)   *4.0.3 *4.0.4
        (4.1)   ~4.1.0-r1 4.1.1 4.1.1-r1 4.1.1-r3 ~4.1.2
        (cvs)   *20101010[5]


4.1.2 - и то ещё ~arch. 
А где ты свою каку взял - это тебя спрашивать надо :D

> и зачем она тебе? ты один из разработчиков/тестеров ГЦЦ или перед девочками вмето пиписьки этим красуешься?
да нет...
по умолчанию ставится последняя...
я как-то особенно не влезал в настройки...
ну ставится 4.3 ну и пусть ставится... (в смысле по портапгрейду ставится)

> в трешке нет флага -ftree-vectorize (кстати, он почему-то и в 4-ке
по умолчанию не включается в -O3), а амд-шники рекомендуют его
включать ( http://www.amd.com/us-en/assets/content_type/
white_papers_and_tech_docs/32035... )

А потом случается вот такое(при сборке с -mfpmath=sse -ftree-vectorize):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1237857392 (LWP 13781)]
_______________________________________________________________________________
eax:081FE4C4 ebx:B67288F8 ecx:00000000 edx:08235F08 eflags:00210246
esi:00000000 edi:081FE4C0 esp:B637BFFC ebp:B637C018 eip:B668C580
cs:0073 ds:007B es:007B fs:0000 gs:0033 ss:007B o d I t s Z a P c
[007B:B637BFFC]---------------------------------------------------------[stack]
B637C02C : 17 5D 74 D1 45 57 5D 40 - F0 C0 37 B6 00 00 00 00 .]t.EW]@..7.....
B637C01C : 77 D4 64 B6 C0 E4 1F 08 - 08 5F 23 08 08 5F 23 08 w.d......_#.._#.
B637C00C : F8 88 72 B6 20 2F 23 08 - 08 5F 23 08 68 C0 37 B6 ..r. /#.._#.h.7.
B637BFFC : 03 00 00 00 06 00 00 00 - 06 00 00 00 06 00 00 00 ................
[007B:081FE4C0]---------------------------------------------------------[ data]
081FE4C0 : C8 7F 8F B6 18 35 AE B6 - 00 00 00 00 00 00 00 00 .....5..........
081FE4D0 : 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
[0073:B668C580]---------------------------------------------------------[ code]
0xb668c580 <_ZN9OutputDev13setDefaultCTMEPd+124>: movapd %xmm1,(%eax)
0xb668c584 <_ZN9OutputDev13setDefaultCTMEPd+128>: add $0x1,%ecx
0xb668c587 <_ZN9OutputDev13setDefaultCTMEPd+131>: add $0x10,%eax
0xb668c58a <_ZN9OutputDev13setDefaultCTMEPd+134>: add $0x10,%edx
0xb668c58d <_ZN9OutputDev13setDefaultCTMEPd+137>: cmp 0xffffffe4(%ebp),%ecx
0xb668c590 <_ZN9OutputDev13setDefaultCTMEPd+140>: jb 0xb668c577 <_ZN9OutputDev13setDefaultCTMEPd+115>
------------------------------------------------------------------------------
0xb668c580 in OutputDev::setDefaultCTM () from /usr/lib/libpoppler.so.1
gdb> i r eax
eax 0x81fe4c4 0x81fe4c4
gdb> x/x 0x81fe4c4
0x81fe4c4: 0xb6ae3518

> А где ты свою каку взял - это тебя спрашивать надо :D
:-)
да не специально я :-)

piter$ pwd
/usr/ports/lang/gcc43
piter$ cat distinfo
MD5 (gcc-core-4.3-20070209.tar.bz2) = fc33f211584f16a65723b5b35cf76dbc
SHA256 (gcc-core-4.3-20070209.tar.bz2) = 52674cc8a3b4cab8ca1251d67f7b6281271a6a9d2e25ed1a021ab820add46b3a
SIZE (gcc-core-4.3-20070209.tar.bz2) = 16759657
MD5 (gcc-fortran-4.3-20070209.tar.bz2) = c0ddb66673ebf59eb565dfcaaa98d88d
SHA256 (gcc-fortran-4.3-20070209.tar.bz2) = 8c98bbcb9035e3a0bce67ccaa569fb1c82598d6b567907157ae9a3be6b0a3d9f
SIZE (gcc-fortran-4.3-20070209.tar.bz2) = 927470
MD5 (gcc-g++-4.3-20070209.tar.bz2) = 13148b14fed8e62e0eecd3ff1257d80a
SHA256 (gcc-g++-4.3-20070209.tar.bz2) = 358a539e9fa1aad0763bc059498d6206086538d2078f8a5d5bb9e53d26d2c836
SIZE (gcc-g++-4.3-20070209.tar.bz2) = 4839059
MD5 (gcc-objc-4.3-20070209.tar.bz2) = e7dd58a1e5e65d016552c94780c22169
SHA256 (gcc-objc-4.3-20070209.tar.bz2) = 661ac9dd8f99272527585157b198adc8eaf6cb12253a0c7c45b54c467e89b18b
SIZE (gcc-objc-4.3-20070209.tar.bz2) = 192156
MD5 (gcc-testsuite-4.3-20070209.tar.bz2) = 33763762d8e9d9cfda184a1ac6324f07
SHA256 (gcc-testsuite-4.3-20070209.tar.bz2) = c2621ce88762031b8869516c0b29a822fc3932c5c80f92db02c28bd45018205d
SIZE (gcc-testsuite-4.3-20070209.tar.bz2) = 3915884
MD5 (gcc-java-4.3-20070209.tar.bz2) = 2faabb27d344f90bf750a5a14ee7d74f
SHA256 (gcc-java-4.3-20070209.tar.bz2) = d79c4c6ec8fda77a06b61d5809aded6d3d26d460313155304c3cba398474949c
SIZE (gcc-java-4.3-20070209.tar.bz2) = 17512562

стоит в портах...
у меня фря... но это собственно не должно особенно на GCC влиять...

Главное условие выпуска - чтобы не было новых регрессий по сравнению с предыдущими версиями. http://gcc.gnu.org/wiki/GCC_4.1.2_Status - порешили, что это не баги и выпустили =)

и оно нормально работает? о_О

в смысле все компилит и потом откомпилированное не слетает по первому чиху?

Хорошая новость. Спасибо.

>А что лучше по производительности GCC 4.x или Intel compiler?

INtel. но он только для соответствующих процов.

>А потом случается вот такое(при сборке с -mfpmath=sse -ftree-vectorize):

>Program received signal SIGSEGV, Segmentation fault.

так надо было данные выравнивать... и march прописывать корректно.

А так - да, векторизатор считает, что указатель на первый элемент цикла выровнен по-умолчанию (на 32/64 бита, в зависимости от -m32/-m64).

>INtel. но он только для соответствующих процов.

он и для amd64 генерит код лучше, чем гцц

>да не специально я :-)

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_...

ты смотри поаккуратнее =)

Ты удивишься, но у многого софта есть разные ветки.

Есть патчи для работы с любыми процами :)

+ он далеко не всё может скомпилить. (ядро не может, например)

да ядро им не скомпилить.

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

видать не осилил =) впрочем я не следил за этим, может и есть такие...

> ты смотри поаккуратнее =)
да уже напугали :-)
уже откатился на 4.1 :-)
сейчас пересобиру и попробую :-)

После обновления до 4.1.2 нужно libC или system пересобирать?

>(ядро не может, например)

4.2

уже может, тем более ядро поддерживает icc ( include/linux/compiler-intel.h )

> После обновления до 4.1.2 нужно libC или system пересобирать? Смотря с чего... world пересобери :)

За это стоит выпить!

> После обновления до 4.1.2 нужно libC или system пересобирать?

не обязательно, т.к. ABI не ломали, но можешь

>уже может, тем более ядро поддерживает icc ( include/linux/compiler-intel.h )

хорошо :) На момент, когда игрался с icc оно не собирплось.

> так надо было данные выравнивать... и march прописывать корректно.

march корректный был прописан. А gcc ничто не оправдывает если в рез-те оптимизации он делает нерабочий код, который валится из-за того, что gcc прописал movapd(move two _aligned_ packed double-precision values) ссылающийся на невыравненные данные.

>А gcc ничто не оправдывает если в рез-те оптимизации он делает нерабочий код, который валится из-за того, что gcc прописал movapd(move two _aligned_ packed double-precision values) ссылающийся на невыравненные данные.

Оправдывает. Ты же не будешь кричать, что гцц во всем виноват, если ты скомпилил что-нить с march=k8 и запускаешь на PIII. А этим флагом(ftree-vectorize) ты задаешь ему принудительную векторизацию. По идее он сам векторизует, если может определить, что данные выровнены, и не векторизует, если не выровнены(при прочих равных условиях). Другое дело, что в мане это криво написано, отсюда и непонятки.

> >(ядро не может, например)

> уже может, тем более ядро поддерживает icc ( include/linux/compiler-intel.h )

а кто-нить это дело (icc) к Gentoo прикручивал? интересны результаты...

И какой прирост от новых флагов? Тесты есть?

> А gcc ничто не оправдывает если в рез-те оптимизации он делает нерабочий код, который валится из-за того, что gcc прописал movapd(move two _aligned_ packed double-precision values) ссылающийся на невыравненные данные.

Конкретно это, вроде бы, в gcc-4.1.2 пофиксили.

> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_... > ты смотри поаккуратнее =)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559

Так вот почему Зюзя так адски тормозит и подвисает - "-О3" виновато!

А мне вот интересно, почему gcc-шники не дизассемблируют скомпиленный на icc код и не подсосут технологию оптимизации?..

Потому что GCC - лицензионно чистый продукт. Тем и берёт обычно.

А при чём тут лицензионная чистота? Ничто не мешает написать мне некий код, скомпилить его icc и дизассемблировать (свой!) код. Другое дело, что какие-то технологии оптимизации могут быть запатентованы.

>Ничто не мешает написать мне некий код, скомпилить его icc и дизассемблировать (свой!) код

Компилятор подключает дофига свих библиотек. Если ты напишешь "Hello LOR" тыщу мульенов раз и работать будет быстрее, то вся разница будет в библиотеках, а они в intel'е собствеенные

Вопрос именно в патентах.

Ибо проверить на нарушение патентов GCC в случае, если они чужие решения задействуют - раз плюнуть, а распространяется GCC не только в России или Европе, но и в Штатах, как это ни удивительно :)

/me поставил icc в очередь осла. Надеюсь, проблем с ядром не будет.

icc всегда можно было скачать с ftp intel'а

зачем ослом качать?

отсюда можно напрямую взять (для некоммерческого использования) http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/219856.htm

достаточно только на оба вопроса Yes ответить

>поставил icc в очередь осла. Надеюсь, проблем с ядром не будет.

Можешь ответить на простой вопрос ?

Нах тебе ядро icc-шкой собирать ? Ты часом не "аптимизатор" ? ;)