LINUX.ORG.RU

GCC 4.5.0 released

 , ,


0

0

GNU и команда разработки GCC рады представить релиз GNU Compiler Collection версии 4.5

В новой версии:

  • Добавлена поддержка плагинов позволяющих менять функциональность компиляторов без пересборки GCC
  • Поддержка оптимизации при компоновке (LTO)
  • Добавлена поддержка библиотеки MPC для улучшения математическо-расчетной части компилятора
  • Поддержка Intel Atom, а также наборов инструкций для новейших процессоров Интел и AMD (XOP,FMA4,MOVBE,LWP)
  • Поддержка новых процессоров ARM, AVR, Coldfire, Atmega, MeP, MIPS, Picochip (см. подробности)
  • Улучшения стандарта C++0x в libstdc++
  • Значительно улучшена подсистема векторизации и параллелизации кода Graphite
  • много других изменений

Анонс релиза

>>> Подробности изменений

★★★★★

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

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

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

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

у меня 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

Sylvia ★★★★★ ()

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

devl547 ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sylvia ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

-fexcess-precision=fast

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

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

Ты про это?
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

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

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

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

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


at compile time

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

>самих плагинов пока еще нет особенно, кроме 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 вполне рабочий

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

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

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

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

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

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

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

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

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