>А gcc (-m64 для 64 бит) -fverbose-asm -march=native -Q --help=target не достаточно разве рассказывает?
как выяснилось нет (

у меня pgo сборка самого GCC выпадает стабильно в ICE на сборке libstdc++

In file included from ../../../../libstdc++-v3/src/pool_allocator.cc:31:0:
/var/tmp/gcc-4.5.0/B/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h: In constructor '__gnu_cxx::__pool_alloc<_Tp>::__pool_alloc() [with _Tp = char]':
../../../../libstdc++-v3/src/pool_allocator.cc:171:18: instantiated from here
/var/tmp/gcc-4.5.0/B/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h:140:30: internal compiler error: Segmentation fault

SliTaz начал пересобираться этой версией) Внезапно так.

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

не нашла в анонсе, плохо смотрю?
вообще в новости если перечислить все, то она станет слишком длинной,
для этого и есть ссылка на подробности в виде официальных release notes,
хотя и там конечно тоже не все, а основное

красноглазые вы ) я вот еще долго с 4.4.x буду

anonymous> один фиг у интела оптимальнее компилятор.

Даже на армах?

можеш сориентировать в надежности генерируемого кода в зависимости от версии gcc4?

для надежности без разницы -
4.4.3 , если вся система им полностью (т.к. есть несовместимость abi)
иначе же - 4.3.4 (еще должен выйти 4.3.5)

4.5.0 рановато еще пусть пионеры из первых рядов понаступают немного на грабли )

вообще переход с 4.3.х (и ниже) системы на 4.4.х и выше может оказаться достаточно болезненным в плане стабильности приложений, так что Патрику в слаке придется достаточно многое пересобрать теперь )

Ага, дня 4 назад я только собрал gcc-4.4.3 >_<

http://gcc.gnu.org/gcc-4.5/changes.html#x86

Сорри за задержку

не обратила внимания, прошло в рамках улучшения стандартов ISO 99
надо будет потестировать как-нибудь, на чем-нибудь насколько это снижает производительность расчетов.

>не нашла в анонсе, плохо смотрю?

opennet>Для x86 архитектур код с плавающей точкой, генерируемый согласно ужесточенным требованиям стандарта C99, будет работать гораздо медленней, чем в старых версиях GCC. Для решения этой проблемы используйте ключ компиляции -fexcess-precision=fast;

Как я понял, оно теперь при каждом чихе будет пытаться приводить 80битное внутреннее преставление вещественного числа в FPU к тому типу, в котором хранится переменная.

>один фиг у интела оптимальнее компилятор.

Были тесты, где он проигрывал.

-fexcess-precision=fast

в любом случае можно вернуть старое поведение, похоже флажок станет популярен )

Ты про это?
GCC now supports handling floating-point excess precision arising from use of the x87 floating-point unit in a way that conforms to ISO C99. This is enabled with -fexcess-precision=standard and with standards conformance options such as -std=c99, and may be disabled using -fexcess-precision=fast.

К тому же кого волнует х87 во времена sse

ну вообще то для x86 -mfpmath=387 по умолчанию пока,
хотя одно из изменений в 4.5, что можно задать -mfpmath по умолчанию )

SSE math now can be enabled by default at configure time with the new --with-fpmath=sse option.


at compile time

>ну вообще то для x86 -mfpmath=387 по умолчанию пока,

К счастью, ну это проблемы только 32-битных бинарных дистрибутивов. И то часть совта собирается с поддержкой sse

>80битное внутреннее преставление вещественного числа в FPU

Это кто-то еще использует?

> -flto -fwhopr ? так да
Играюсь сейчас с релизом, вспомнил про этот топик и эти ключики.
сс1 ругается так: -flto and -fwhopr are mutually exclusive
То есть вместе никак не выйдет.

>сс1 ругается так: -flto and -fwhopr are mutually exclusive

То есть вместе никак не выйдет.

причем это отключили непосредственно перед релизом, в RC они нормально сочетались и даже вроде работали

>Это кто-то еще использует?

http://en.wikipedia.org/wiki/SSE2

>http://en.wikipedia.org/wiki/SSE2

И что? Кто-то еще использует x87? Который, кстати, не поддерживается в современных ОС.

несовместимость abi

> 4.4.3 , если вся система им полностью (т.к. есть несовместимость abi) иначе же - 4.3.4 (еще должен выйти 4.3.5)

а можно о несовместимости ABI поподробней и со ссылками? + о каком ABI речь идет?

http://gcc.gnu.org/gcc-4.4/changes.html

см Caveats:

Packed bit-fields of type char were not properly bit-packed on many targets prior to GCC 4.4. On these targets, the fix in GCC 4.4 causes an ABI change.

Как наиболее частое проявление - нестабильность Firefox

*THANKS*

http://www.opennet.ru/opennews/art.shtml?num=26283
http://www.phoronix.com/scan.php?page=article&item=gcc_45_benchmarks&num=1

вот и тесты.. от вороникса, но других так быстро пока ждать не приходится

Ждем тестов от Сильвироникса ;)

>with the only configuration being defining the x86_64-linux-gnu target and leaving all other options at their defaults

Ну как обычно.

>самих плагинов пока еще нет особенно, кроме example )

если кому попадались - киньте ссылочку

1. Google Go компилятор http://golang.org/doc/gccgo_install.html http://gcc.gnu.org/ml/gcc/2009-11/msg00297.html , тот, который на базе gcc (gccgo), а не на базе Plan9 компиляторов (6g,8g) — реализован как плагин к gcc 4.5, грозились войти в апстрим gcc. Реализация собственно фронтенда на gcc 4.5 плагином — явно симпатичнее, сравнивал gdc в gcc 4.3 и gccgo в gcc 4.5, 4.5 прозрачнее.
Кстати, использование gcc в go имело смысл: к примеру, FFI реализован очень просто: http://golang.org/doc/gccgo_install.html#Automatic_generation_of_Go_declarati... gccgo -E ... xxx.go генерирует asm исходник *.S с метками-комментариями, по которыми grep -V подготовит список деклараций функций-прототипов
2. DragonEgg http://dragonegg.llvm.org/ плагин к gcc 4.5 из LLVM, который должен заменить llvm-gcc версии 4.2. Самособирается, self-hosted, http://blog.llvm.org/2010/02/dragonegg-successfully-self-hosts.html так что DragonEgg вполне рабочий

>Кажется, просто-напросто отопильщики - это такие гентушники, которые компиляют свою генту на кластере, системой охлаждения которого является система центрального отопления. А что? Дёшево и сердито. Ещё и бабла на новый кластер глядишь насобирают.

да, а изменения в тарифах вызваны новой версией gcc, который компиляет всё медленнее и медленнее

>То, что поддержкой gcc3 никто не занимается не означает, что он был бы медленнее.

FIXED: То, что поддержкой gcc3 никто не занимается не означает, что он был бы

спасибо, да dragonegg забыла,googlego пока слишком узкую сферу применения имеет наверное ))