После года разработки и спустя 25 лет после основания проекта представлен (http://permalink.gmane.org/gmane.comp.gcc.devel/125441) релиз новой ветки свободного набора компиляторов GCC 4.7 (http://gcc.gnu.org), развиваемого проектом GNU. В новой версии реализованы новые методы оптимизации, прекращена поддержка устаревших систем, расширена поддержка стандартов C++11 и C11, реализована поддержка транзакционных блоков для C/C++, улучшена поддержка языка Google Go, обеспечена поддержка процессоров ARM Cortex-A7, Intel Ivy Bridge, Intel Haswell и AMD Fusion Piledriver.
Основные изменения (http://gcc.gnu.org/gcc-4.7/changes.html):-
Улучшения в оптимизации кода:- Улучшение фреймворка оптимизации во время динамического связывания (LTO - Link Time Optimization) - проведена работа по увеличению масштабируемости, повышению стабильности и сокращению потребления ресурсов. Например, для использование LTO для Firefox на 64-разрядной системе достаточно 3 Гб ОЗУ, в то время как ранее требовалось 8 Гб.
- Ускорены операции связывания (linking). Например, связывание компонентов Firefox ускорилось в 10 раз). Сокращён размер объектных файлов и уменьшено дисковое пространство, необходимое для хранения временных данных в процессе связывания;
- Улучшены эвристические методы inlinе-раскрытия функций, дополнительно учитывающие известные значения параметров функции. Например, для кода
<font color="#461b7e">
void foo(int a)
{
if (a>10)
... много кода ...
}
void bar (void)
{
foo (0);
}
</font>
код функции foo будет развёрнут внутри bar, даже в ситуации вколчения режима оптимизации по размеру (изначально известно что блок "много кода" при нулевом аргументе никогда не будет вызван).
- Улучшены внутрипроцедурные оптимизации размещения констант. Например, при компиляции кода<font color="#461b7e">
void foo(bool flag)
{
if (flag)
... do something ...
else
... do something else ...
}
void bar (void)
{
foo (false);
foo (true);
foo (false);
foo (true);
foo (false);
foo (true);
}
</font>GCC сгенерирует две копии функции foo, одна для флага true, и другая для флага false;
- Добавлены новые оптимизации строковых операций, основанные на отслеживании размера строк и пытающиеся оптимизировать использование функций strlen, strchr, strcpy, strcat и stpcpy. Например, оптимизатор заменит "strcpy (a, b); strcat (a, c); strcat (a, d);" на "strcpy (stpcpy (stpcpy (a, b), c), d);";
-
Изменения в поддержке языков C и C++:
- В компиляторе C++ обеспечена поддержка большей части стандарта ISO C++11 (http://www.opennet.me/opennews/art.shtml?num=31476), включая поддержку атомарных операций, модель памяти C++11, нестатические инициализаторы членов классов, определяемые пользователем литералы, псевдонимы-декларации, вызов конструкторов класса из других конструкторов этого же класса, расширенный синтаксис декларатора классов friend и т.п. В runtime-библиотеке libstdc++ обеспечена экспериментальная поддержка C++11. Управление поддержкой C++11 осуществляется через опции -std=c++11, -std=gnu++11 и -Wc++11-compat;- В компиляторе Си добавлена поддержка дополнительных элементов, определённых в стандарте ISO C11 (http://www.opennet.me/opennews/art.shtml?num=32644), например, Unicode-строки, выравнивание (_Alignas), не возвращающие значения функции, макросы CMPLX. Управление поддержкой C11 осуществляется через опции -std=c11 и -std=gnu11;
- Экспериментальная поддержка в компиляторе транзакционной памяти (http://gcc.gnu.org/wiki/TransactionalMemory) и создание сопутствующей библиотеки libitm. Транзакционная память определяется конструкцией __transaction_atomic { ... } и позволяет (http://lwn.net/Articles/466513/) обеспечить атомарное выполнение блока кода, все результаты работы которого будут или полностью видны для других нитей или невидны совсем. Поддержка транзакционной памяти пока обеспечена для платформ x86-32, x86-64 и Alpha, для включения поддержки при сборке следует использовать опцию "-fgnu-tm";
-
Улучшения в поддержке процессорных архитектур:- Поддержка процессоров ARM Cortex-A7 (опция для включения -mcpu=cortex-a7), Texas Instruments C6X, Tilera TILE-Gx и TILEPro, Adapteva Epiphany, National Semiconductor CR16,
- Из улучшений для архитектуры x86 отмечается поддержка семейств процессоров Intel Ivy Bridge (-march=core-avx-i), Intel Haswell (-march=core-avx2) и AMD 15h/Piledriver (-march=bdver2), продолжающих развитие AMD Fusion APU. Процессоры Intel Haswell поступят в продажу только в следующем году и будут отличаться поддержкой расширенных инструкций AVX2, FMA, BMI, BMI2 и LZCNT;
- Поддержка расширенных наборов инструкций процессоров IA-32/x86-64:
Intel AVX2 (-mavx2), Intel BMI2 (-mbmi2), Intel FMA3 (-mfma), Intel rdrnd (-mrdrnd), дополнительных векторных преобразований AVX (-mf16c);
- Поддержка архитектуры семейства микроконтроллеров XMEGA AVR (ATxmegaxxx);-
Разное:- Предварительная поддержка первой версии стандарта (http://weekly.golang.org/doc/go1.html) языка программирования Go. Довести до конца поддержку всех элементов спецификации планируется в выпуске GCC 4.7.1;
- Поддержка различных расширений GNU для отладочного формата DWARF, таких как контроль входящих значений и получение информации о вызовах. Поддержка данных расширений ожидается в GDB 7.4;- Большая порция улучшений для языка Фортран;
- Поддержка в компиляторах C, C++ и Fortran спецификации OpenMP 3.1 (http://openmp.org/wp/openmp-specifications/).-
Общие нюансы:- Объявлены устаревшими и будут удалены в следующих выпусках порты IRIX 6.5 (mips-sgi-irix6.5), MIPS OpenBSD (mips*-*-openbsd*), Solaris 8 (*-*-solaris2.8) и Tru64 UNIX V5.1 (alpha*-dec-osf5.1*).
- Переведены в разряд устаревших порты ARM, поддерживающие только устаревший акселератор вычислений с плавающей запятой (FPA) и смешанный формат кодирования чисел с плавающей запятой. Большинство портов для устаревших систем ARM будет сохранено, так как они поддерживают альтернативный формат кодирования чисел с плавающей запятой (VFP). Среди подлежащих скорому удалению портов, для которых есть остающиеся в составе альтернативы: arm*-*-rtems (замена arm*-*-rtemseabi), arm*-*-linux-gnu (замена arm*-*-linux-gnueabi), arm*-*-elf (замена arm*-*-eabi), arm*-*-uclinux* (замена arm*-*-uclinux*eabi). Устаревшие порты для которых нет замены на базе VFP: arm*-*-ecos-elf, arm*-*-freebsd, arm*-wince-pe*;
- Объявлена устаревшей поддержка сопроцессора Maverick для ARM
- Удалена поддержка конфигурации для NetWare x86;
- Убрана поддержка архитектур, объявленных (http://www.opennet.me/opennews/art.shtml?num=30035) устаревшими в GCC 4.6.0;
URL: http://permalink.gmane.org/gmane.comp.gcc.devel/125441
Новость: http://www.opennet.me/opennews/art.shtml?num=33424
Где есть тесты разных версий компиляторов за последних 10 лет, насколько скорость выросла?
> Где есть тесты разных версий компиляторов за последних 10 лет, насколько скорость выросла?Капитан сообщает: www.phoronix.com - не сакажу про 10 лет но бенчи они любят, в том числе недавно были и бои между разными версиями gcc :)
> www.phoronix.com - не сакажу про 10 лет но бенчи они любятк сожалению, это невзаимно.
> к сожалению, это невзаимно.Это как? Бенчи не любят phoronix? :)
>> к сожалению, это невзаимно.
> Это как? Бенчи не любят phoronix? :)типа того. потому получаются какие-то дурацкие.
http://www.freshports.org/lang/gcc48/Чего-то я не понял:
17 Mar 2012 00:16:16
4.7.0.20120225
Complete repocopy of lang/gcc47 to lang/gcc48.и далее:
17 Mar 2012 11:22:17
4.8.0.20120311
Welcome GCC 4.8! For the next couple of months this is going to be
a rougher ride, as this release series -- just branched off GCC 4.7
-- is going to see a lot of active and often invasive development.
This port is for early exposure and not production use at all.Выходит, что отделилась ветка GCC 4.8, правда, не для продакшена. Ветка GCC 4.7 объявлена неперспективной.
отрелизилась 4.7, пошла разработка 4.8
> отрелизилась 4.7, пошла разработка 4.8Очень странно что такие вещи надо объяснять фанату сборки софта из сырцов, правда? ;)
Во фряхе порты - это не сборка из сырцов как таковая. Пользователь сам ничего не собирает - мозговых усилий примерно столько же, сколько требуется для установки пакета в убунте. Плюс в том, что можно компоненты легко включить/отключить.
Для протокола: ты вот прям только щас назвал яЗена безмозглым фанатом? Нееееееет!!
>> Пользователь сам ничего не собирает - мозговых усилий примерно столько же, сколько требуется для установки пакета в убунте.Не совсем так. Если в убунте пакет чаще всего устанавливается (ибо хоть как-то протестирован в единственно доступной собранной конфигурации), то при сборки из сорцов вариантов куда больше (всякие директивы компиляции, различные версии зависимых библиотек, опции компилятора и т.д.), поэтому без проблем оно устанавливается куда реже. Ну а в этих случаях "мозговые усилия" еще как нужны... Хотя, да, гибкость выше.
Я ж все же про порты. Сломанных не так много (redmine, к примеру). Но все остальное у меня собирается постоянно и успешно. Правда году в 2009-м наткнулся на циклическую зависимость - было забавно.
Это текущий снеп транка, меняющийся раз в неделю. Для заинтересованных девелоперов.Во фре порты по возможности создаются копиями с имеющихся в наличии, вот и gcc4.8 с gcc4.7 слизали, по доступности версию и хеши файлов обновят.
> Это текущий снеп транка, меняющийся раз в неделю. Для заинтересованных девелоперов.
> Во фре порты по возможности создаются копиями с имеющихся в наличии, вот
> и gcc4.8 с gcc4.7 слизали, по доступности версию и хеши файлов
> обновят.% cd /usr/ports/lang/gcc48/ && make checksum
Making GCC 4.8.0.20120311 for FreeBSD 9.0 target=x86_64-portbld-freebsd9.0
===> License check disabled, port has not defined LICENSE
=> gcc-4.8-20120311.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.c...
gcc-4.8-20120311.tar.bz2 2% of 75 MB 103 kBps 12m00s^C
fetch: transfer interrupted
> Выходит, что отделилась ветка GCC 4.8, правда, не для продакшена. Ветка GCC 4.7
> объявлена неперспективной.Ты что, совсем криведко и не понимаешь чем застабилизированная ветка отличается от ветки которая крушится т.к. в ней идет основная разработка? Я почему-то думал что ты не настолько ракообразный.
> Выходит, что отделилась ветка GCC 4.8, правда, не для продакшена. Ветка GCC
> 4.7 объявлена неперспективной.Да-да, а во вчерашнес снэпе шланга объявили неперспективным тебя. Скоро попатчат!!
изя, ты риальне дерево.
> изя, ты риальне дерево.Более того, это дерево, хотя и вопит о том как все круто собирать из сорцов и как ему надо что-то там зажать, судя по всему вообще ни в зуб ногой о том как происходят процессы разработки софта. Epic fail :)
ну так он и жабу-то уже лет 10 учит, а воз всё там, где был…
за последние несколько дней: linux 3.3.0, glibc 2.15, gcc 4.7.0 ... просто праздник какой-то :-D
Праздник компиляции! :)
праздник багов! теперь еще 2-3 версии в gcc будут файлы с сборкой разных проектов.
> праздник багов!А что, вы уже нарвались на какой-то баг?
>> праздник багов!
> А что, вы уже нарвались на какой-то баг?ага. баг с volatile, когда при некоторых условиях gcc падает в кородамп. древний такой. знать не знаю, отчего, и редуцировать до багрепорта не могу: просто чертыхаюсь и вожу volatile туда-сюда по тексту, пока падать не перестанет.
Самое важное в новости забыли
Support for the x32 psABI is now available through the -mx32 option.
не плохо.
теперь подумать как это применить у себя.
https://sites.google.com/site/x32abi/
там есть гентушный образ. Только ядра нет, кажется, но патч просто наложить. gcc в образе кривой, у меня ничего не собирал, так что лучше сразу поставить свой и немного помудрить с симлинками.
спасибо за ссылку.
стэйдж в тему, буду посмотреть.
Улучшены эвристические методы inlinе-раскрытия функций, дополнительно учитывающие известные значения параметров функции. Например, для кодаvoid foo(int a)
{
if (a>10)
... много кода ...
}
void bar (void)
{
foo (0);
}код функции foo будет развёрнут внутри bar, даже в ситуации включения режима оптимизации по размеру (изначально известно что блок "много кода" при нулевом аргументе никогда не будет вызван).
объясните имбицилу - для чего это делать и в чем тут плюс...
> объясните имбицилу - для чего это делать и в чем тут плюс...Если foo() больше никто не вызывает, "многа кода" будет оптимизирован до размера 0.
Будут созданы две функции к примеру:
foo_if_a_gt10()
foo_if_a_eq10()
foo_if_a_lt10()
и все вызовы foo() будут заменены вызовами одной из этих функций.
> Будут созданы две функции к примеру:Три т.е., пардон.
соответственно это для трех условий.
в случае одного условия гцц и так раньше все оптимизировал.
>> Будут созданы две функции к примеру:
> Три т.е., пардон.Зачем/откуда из _одного "if (a>10)" -- три варианта??
код функции foo БУДЕТ РАЗВЕРНУТ внутри bar, даже в ситуации включения режима оптимизации по размеру
0 ни как не получается, или я чет ни так понимаю...
void foo(int a)
{
if (a>10)
... много кода ...
}
void bar (void)
{
foo (0);
}превратится в
1.
void bar(int a)
{
if (a>10)
;
}2.
void bar(int a)
{
if (a>10)
asm("nop");
}3.
void bar(void)
{
asm("nop");
...
...
}4.
void bar(void)
{
...
...
}
---
Зря поддержку Solaris 8 удаляют. Он еще много где используется.
> Зря поддержку Solaris 8 удаляют. Он еще много где используется.так старые версии компиляторов никто не запрещает же.
> Зря поддержку Solaris 8 удаляют. Он еще много где используется.... но видимо не разработчиками gcc. Древним системам - древний софт :)
>> Зря поддержку Solaris 8 удаляют. Он еще много где используется.
> ... но видимо не разработчиками gcc. Древним системам - древний софт :)дык я так понимаю, что человеку вот нужна восьмая соляра. наверное, нашёлся новый маинтайнер?
> Например, оптимизатор заменит "strcpy (a, b); strcat (a, c); strcat (a, d);"
> на "strcpy (stpcpy (stpcpy (a, b), c), d);";Тыц...
Блин, муики... оно не собирается под 64-бита!!!---
checking for x86_64-pc-linux-gcc... -m32 option to accept ISO C89... unsupported
checking how to run the C preprocessor... /lib/cpp
configure: error: in `/usr/src/GCC/gcc-build/x86_64-pc-linux/32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check---
Чёй-то капаю не найду как вырубить 32-х битность.