LINUX.ORG.RU

GCC 3.4.2


0

0

В этом релизе:
- исправлено много внутренних ошибок компилятора
- исправлены ошибки оптимизации, в т.ч. -02
- лучшены параметры компилятора C++

Таким образом это bug-fix релиз, т.к. сейчас активно ведётся разаработка GCC 3.5

Список исправлений:
http://gcc.gnu.org/gcc-3.4/changes.ht...

Зеркала для скачивания:
http://gcc.gnu.org/mirrors.html

>>> Подробности

★★★★★

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

>>Таким образом GCC 3.4.2 это bug-fix релиз, т.к. сейчас активно ведётся >>разаработка GCC 3.5
А какого они 3.3.x до сих пор развивают ? Где логика ? Что нового будет в 3.5.x ???

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

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

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

>А если glibc и остальные общие библиотеки с -O3 скомпилить, глючить не будет?
У меня crux давно стоит, обновляю через порты, все компилится с -O3,
обновлено уже более половины пакетов,
пока ничего не глючит, но glibc пока не обновлял

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

>А безопасно ли щас всю систему строить на -O3?

всю систему лучше не строить, -O3 лучше использовать только для определенных пакетов, где тебе действительно нужны те дополнительные 2% производительности (графические приложения и различные программы мультимедиа), и где легко можно проверить пакет на "глючность"

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

Хм, а будет ли когда нибудь возможность компилить с -O3 и ядро и всё остальное без проблем, или это по определению импосибл?

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

Когда это случиться -O3 переименуют в -O2 ;)

anonymous
()

> - лучшены параметры компилятора C++

лучшены-лучшены, но так и не улучшены

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

>Ядро не любит -O3

аргументируй! уже пару лет в мэйкфайлы "-O3" вписываю,
с gcc 2.95.3 до 3.4.2, с kernel 2.2.5 до 2.6.8.
может я везучий, но отличий от "-O2" не было.

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

Да проблемы то не на стадии работы. Уж если собралось с -O3, то работать будет, другое дело что может не собраться и вывалиться с ошибками. Скажем какой-то media player где sse команды написаны на ассемблере у меня не собирался с -O3.

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

> А какого они 3.3.x до сих пор развивают ? Где логика ? Что нового будет в 3.5.x ???

3.3 типа самый стабильный.

В 3.5 будет переделан оптимизатор на Static Single Assignment (SSA) - http://gcc.gnu.org/projects/tree-ssa/ Если коротко - оптимизатор должен стать ещё лучше.

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

> аргументируй! уже пару лет в мэйкфайлы "-O3" вписываю, 

"Поздравляю тебя, Шарик, ты балбес !" (c)

Из доки gcc:
`-O3'
     Optimize yet more.  `-O3' turns on all optimizations specified by
     `-O2' and also turns on the `-finline-functions' and
     `-frename-registers' options.

Ну и нафига спрашивается при компиляции ядра -finline-functions ?

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

По поводу того, что можно собирать с -O3, а что нельзя, могу порекомендовать книгу LFS. Там четко указано, какие пакеты не любят флаги оптимизации. Например, ядро/модули и GRUB. Это то, с чем я сам сталкивался. По собственному опыту могу сказать, что сборка с высоким уравнем оптимизации (-O3, -march etc.) целесообразна только для тяжелых приложений, и приложений, сильно использующих ресурсы системы (OO, mplayer/mencoder etc.). С остальными лучше не заморачиваться - ничего это не даст. Интересующимся могу посоветовать прочитать цикл статей Федорчука про оптимизацию приложений с GCC.

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

> Интересующимся могу посоветовать прочитать цикл статей Федорчука про оптимизацию приложений с GCC

Садист :(

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

>оптимизатор должен стать ещё лучше.
Кстати не факт - оне вот недавно в рассылке ругались что на mainline оптимизация местами говенная и надо отложить релиз на полгода. Но не отложили.

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

SSA само по себе оптимизации не добавляет. Они говорят что SSA даст больше optimization opportunities, т.е. SSA это фреймворк, в который будут вписывать новые и новые оптимизации.

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

> аргументируй! уже пару лет в мэйкфайлы "-O3" вписываю,

Да очень просто, у меня звуковуху и пару скази-адаптеров ядро не видело, и именно с ключом -O3. Глубже я не разбирался, для меня и эти параметры критичны ;)

Так что тебе явно везёт ;)

А вот ещё zsnes отказывается собираться с какой-либо оптимизацией, кроме как -Os(оптимизировать размер), в принципе это по-барабану, он практически весь на асме написан, да и валится он всего на одном файлике, можно и обмануть. В сырцах DOSEMU написано, что -finline-functions не нравится, используйте -O2.

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

>>могу порекомендовать книгу LFS.
Адресок русского перевода не напомнишь ?

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

> По поводу того, что можно собирать с -O3, а что нельзя, могу порекомендовать книгу LFS. Там четко указано, какие пакеты не любят флаги оптимизации.

Я для тех же целей могу порекомендовать еще Gentoo portage tree =) Выкачиваешь тарболл и смотришь, какие ebuild'ы отсекают какие флаги. Например, OpenOffice с -O3 собрать проблематично...

int19h ★★★★
()
Ответ на: комментарий от x-term

>media player где sse команды написаны на ассемблере у меня не собирался с -O3.

Взглянем на mplayer - там местами -O4

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

>прочитать цикл статей Федорчука

Он уже про линукс и фрибсд как-то написал - весь ЛОР угорал, включая новичков. Редкостная чушь была. Думаю, что про gcc статьи не лучше.

У -O3 смысл один (если грубо выразиться) - собрать приложение как с -O2, только сделать его меньшего размера.

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

> У -O3 смысл один (если грубо выразиться) - собрать приложение как с -O2, только сделать его меньшего размера.

Уважаемый, ты глубоко неправ. В большинстве случаев результат будет больше размером. Кроме того, -O4 эквивалентен -O3 в GCC.

В дополнение позвольте отметить, что потуги GCC на оптимизацию выглядят просто смешно по сравнению с, к примеру, Intel Compiler на Pentium4/AthlonXP, или с SunPRO Compiler на UltraSPARC II.

Единственное достоинство GCC в portability, а кроме этого данное поделие очень криво внутри, как и все к чему приложил руку RMS. GCC когда-нибудь станет достойным компилятором, но до этого времени еще далеко.

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

> У -O3 смысл один (если грубо выразиться) - собрать приложение как с -O2, только сделать его меньшего размера.

Ты путаешь с -Os ;)

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

> Взглянем на mplayer - там местами -O4

Да хоть -O100, всё равно максимум -O3

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

> Ядро нормально работает на -O3

Читать все посты, и больше не писать подобной чуши!

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

с -O3 все прекрасно собирается. Вчера запустил сборку gentoo - сегодня все работает и ничего не глючит. Тоесть с -О3 собиралось все кроме ядра.

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

>>>Тоесть с -О3 собиралось все кроме ядра

Это заблуждение.

Многие *.ebuild модифицируют флажки оптимизации из make.conf (и не всегда оптимальным образом). Касательно ядра, действительно есть проблемы при -О3 (точнее из-за -finline ). Впрочем, эта ситуация сильно зависит от текущего ядра и компилера, а также не всегда проявляется сразу.

V0ID ★★★
()

-O9 -fomit-frame-pointer -foptimize-sibling-calls -falign-functions=32 -falign-labels=32 -falign-loops=32 -falign-jumps=32 -march=pentium4 -mcpu=pentium4 -mfpmath=sse -msse2 -mpreferred-stack-boundary=2 -pipe -s

Это то, чем я всегда собираю ядро (правлю на этот предмет makefile'ы). Работает все без нареканий. В том числе, на двухпроцессорных машинах. Это что касается серверных приложений (апач, мускл, самба, бинд и т. д.).

На юзерских приладах проблем тоже нет: собрал таким образом ядро, открытый кусок драйвера NVidia, библиотеку SDL и DoomsdayHQ. В итоге имею милую игрушку Hexen в аппаратном OpenGL... без тормозов и лажи.

Интересно, что я сделал неправильно?

P. S. Комп - Celeron-1700 (sock-478), 512Мб PC-133, NVidia Ti 4200.

R00T
()

в gcc 3.3.3 (который сейчас в NetBSD по дефолту) стопудово есть баги в комбинации -O3 -march=pentium

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