Мдя, странное все-таки поведение. Неужели разработчики не знали, что четверка еще не совсем доработана??? И неужели они не могли оставить ее с такими серьезными недоработками в дальнейшем статусе девелопмент??? Хотя с другой стороне они конечно могут хотеть привлечь к тестированию побольше народа...

интересно, как в федоре собрали kde тестовыми версиями gcc4?

ждем патчей от rh

Нда, чуть было не поставил себе. Черт с ним, с КДЕ, но ведь и ядро-то не компилируется. Да и сам собой же он не собирается. Однако странная ситуация...

>Полностью переписать оптимизатор и не ухудшить положение вещей в >значительной степени - это настоящее достижение

Спрашивается, зачем тогда переписывали?

/me тихо и спокойно сидит на 3.3.5 и не дергается

Те кто хоть немного следил за разработкой gcc4 давным давно знали о таком положении дел с оптимизатором. Была поменяна вся инфраструктура оптимизатора. Конечно поначалу она в некоторых случаях будет даже хуже оптимизировать чем пред. версии gcc (оптимизатор которого тюнился годами!). Зато в перспективе (да и прямо сейчас) это позволит делать оптимизатору то, что раньше было просто невозможно для пред. версий gcc (автовекторизация...).

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

> Да и сам собой же он не собирается.

Ты хоть понял, что ты сказал? Компилятор всегда собирается сам собой в процессе сборки.

> Зато в перспективе (да и прямо сейчас) это позволит делать оптимизатору то, что раньше было просто невозможно для пред. версий gcc (автовекторизация...).

На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

Может, в нём ещё и поддержки OpenMP нет?

А по моему вполне нормальная ситуация.
Помню сколько вони было на 3.0.0 по выходу.
Holy wars и транспаранты 2.93 нам отец родной 3.0.0 ф топку. Он тормоз, глюк, ядро им не собирается и сам собой он собирается.

"сам собой" это как ? как могут исходники собрать себя сами ?

> Спрашивается, зачем тогда переписывали?

Чтобы перейти на новую ступень на пути к совершенству.

> /me тихо и спокойно сидит на 3.3.5 и не дергается

Вот именно из-за таких тихих и спокойных процесс разработки и тестирования тормозится. Не то чтобы паразит, но что-то вроде этого. В нынешнем состоянии gcc подошёл к пределу возможностей оптимизации. Далее нужны существенные переработки, чтоб двигаться дальше. Они и были сделаны. Но некоторые бобры под корягой предпочитают бубнить.

> "сам собой" это как ? как могут исходники собрать себя сами ?

сначала исходники gcc4 собираются предыдущей версией, например 3.4 или 3.3

потом полученным компилером снова снова собираются эти же исходники

ну эт я знаю:)), просто фраза некорректная была, и еще это делается не в процессе простой сборки компилятора, а в ходе бутстрапа (некоторые переводят как шнуровка) системы

Интересно, а как самый первый компилятор делали? Как его собирали?

>>Интересно, а как самый первый компилятор делали? Как его собирали? Спроси у lumag: > Ты хоть понял, что ты сказал? Компилятор всегда собирается сам собой в процессе сборки.

>На данный момент ошибка с компиляцией KDE решена, и патч появится в ближайшее время

Шиза. На каждую прогу - свой патч.

> и еще это делается не в процессе простой сборки компилятора, а в ходе бутстрапа ... системы

Это делается каждый раз кроме кросскомпиляции компиляторов.

И не шнуровка, а вытягивание себя за собственные шнурки :)

2 Whoo:

> На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

В танке?

> Может, в нём ещё и поддержки OpenMP нет?

Типа умный, да, про OpenMP слышал? :)

> > На данный момент ошибка с компиляцией KDE решена, и патч появится в ближайшее время

> Шиза. На каждую прогу - свой патч.

Почему на прогу? Это патч обычного regression, коих в GCC a.b.0 всегда полно.

> Интересно, а как самый первый компилятор делали? Как его собирали?

А и правда - что первично? Таки курица или таки яйцо?

> А и правда - что первично? Таки курица или таки яйцо?

В смысле, написан ли первый компилятор на компьютере или первый компьютер собран компилятором? ;)

Курица, вестимо. Компилятор, на сколько я представляю, писался на ассемблере в hex-кодах... Ну или 8-ричных, 7-ричных, 31-ричных, смотря какая машина :)

Месье никогда не писал в 16-ричных кодах вручную рассчитывая смещения, подбирая нужный формат команды, адресации и т.п.? Месье много потерял! :)

> Месье никогда не писал в 16-ричных кодах вручную рассчитывая смещения, подбирая нужный формат команды, адресации и т.п.? Месье много потерял! :)

Фу, какая гадость. Вот MACRO-11, да, были времена :)

Вручную писали. В машинных кодах. :-)

неет, на яве скорее всего :)

> Интересно, а как самый первый компилятор делали? Как его собирали?
Почитай историю создания языка FORTRAN - там ты найдещь ответ. :)

А что Fortran? В истории C свой ответ имеется. ;-)

А то что он действительно был первым, самым первым компилятором с языка высого уровня, а цэ - нет. :) Впрочем можно почитать и историю создания ALGOL 60 - он хоть и был вторым, но тоже раскручивался с нуля.

Была замечательная сказка

"Как рубанок сделал рубанок". Это из той же оперы :)

// dremin

Круче было с lisp 1.5 в 62 году - тогда лисп скомпилировал сам себя выполняясь своим интерпретатором.. Впервые в истории. :)

Компилятор естесственно был написан на лиспе. :)

> > На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

> В танке?

Применительно к GCC - не слишком слежу за его прогрессом, ибо пользуюсь оным только опосредованно (т.е. пользуюсь только программами, скомпилированными оным). Так что, я правильно понимаю, что на начало 2005-го года GCC ещё не умеет самостоятельно код на SSE/SSE2/3DNow! раскладывать? Уууу...

> > Может, в нём ещё и поддержки OpenMP нет?

> Типа умный, да, про OpenMP слышал? :)

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

(Правда, не под GCC, разумеется. Куда уж этому убогонькому...)

А нафиг когд расскладывать на SSE/SSE2/3DNow! он может компилировать с учётом этих расширений и оптимизировать с их учётом.
Что ещё нужно?
А OpenMP если я неошибаюсь... гдето точно есть! Я не спец но вовремя гугливания натыкался на gcc+OpenMP.

если бы это было так, то бустрап ничем бы не отличался от сборки гцц, глибсов и сопутствующих утил, и его бы не выделили в отдельную процедуру процесса установки системы from scratch. И я у себя никогда не наблюдал повторной сборики при emerge (-u) gcc

http://www.openmp.org/drupal/node/view/9 ... Shareware/Freeware ... + ifc && icc поддерживают OpenMP. PathScale тоже включили поддержку в свои продукты.

2random_code: Есть патчик, после наложения которого не собирается только. i2c в ядре. Может еще что-нибудь не слишком распространеное из модулей. Остальное работает, полёт нормальный.

> И я у себя никогда не наблюдал повторной сборики при emerge (-u) gcc

Если только Gentoo не слишком все поменяли, почти в конце сборки gcc загляни в каталоги сборки gcc. Там и найдешь объектники от stage1 (cc собирает gcc), stage2 (gcc, скомпилированный cc, собирает сам себя) и stage3 (gcc, скомпилированный gcc, собирает себя еще раз, чтобы сравнить с результатом второй стадии. На этом этапе при разработке отлавливаются многие ошибки). При этом понятно, почему в ходе кросскомпиляции gcc собирается только один раз.

P.S. cc = системный компилятор, gcc = вновьсобираемый gcc.

> "Как рубанок сделал рубанок"

http://cm.bell-labs.com/who/ken/trust.html

> Шиза. На каждую прогу - свой патч.

avtoram KDE nado pomen'she juzat' tak nazyvaemye GCCisms (nedokumentirovanye side-effect'y GCC konkretnoj versii)

тов фубар

нет перфокарточку зубами грызли=)

Ну, то что C был не первым, ничего не меняет. Он не был написан ни на алголе ни на фортране.

2Whoo (*) (08.05.2005 5:27:25)

>(Правда, не под GCC, разумеется. Куда уж этому убогонькому...)

То, что вы выучили слово "OpenMP" и собрали с помощью ICC (на PGC или PathScale у вас вряд ли хватит денег ... вряд ли вы работаете на их триалках) пару примеров с его использованием еще не означает что можно нести пургу насчёт gcc.

Для остальных докладываю что проект с использованием OpenMP и gcc называется GOMP.

Кроме этого ещё есть более старый опенсорсный проект - OdinMP

> А нафиг когд расскладывать на SSE/SSE2/3DNow! он может компилировать с учётом этих расширений и оптимизировать с их учётом.

Поясните, как вы понимаете эту фразу, и как вы понимаете её отличие от "раскладывать на SSE/SSE2/3DNow!".

Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил. А у icc 8.1 сразу получилось. Как говорил Жванецкий : "тщАтелней надо , товарищи"

> То, что вы выучили слово "OpenMP" и собрали с помощью ICC (на PGC или PathScale у вас вряд ли хватит денег ... вряд ли вы работаете на их триалках) пару примеров с его использованием еще не означает что можно нести пургу насчёт gcc.

Интересная у вас дихотомия OpenMP-щных компиляторов - на ICC и PGC/PathScale...

> Для остальных докладываю что проект с использованием OpenMP и gcc называется GOMP.

Ух ты! Есть, оказывается! А подскажите, пожалуйста, остальным (а то и, простите за назойливость, даже мне), насколько полноценно оный GOMP работает? Или хотя бы насколько быстро развивается? А то зашёл я к ним на сайт, посмотрел в ихний CVS и увидел там мееелкую кучку файлов двухлетней давности с ревизиями 1.1, 1.2 да 1.3...

Так что, есть в GCC поддержка OpenMP, или (тяжело вздохнув) таки нет?...

Если на самом деле нет, то... ууу... с появлением двуядерных процессоров вас ждёт много интересных (и наверняка не слишком привлекающих новых пользователей) статей про сравнение производительности софта под Линуксом и его конкурентами.

> Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил.

"Тяжело искать чёрную кошку в тёмной комнате. Особенно если её там нет." :)

>> Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил.

>"Тяжело искать чёрную кошку в тёмной комнате. Особенно если её там нет." :)

И как вам такое удаётся ?

hint: К примеру gcc для х86_64 генерит SSE2 код по дефолту. Чтоб заюзать x87 нужно специально подкрутить опции компилера...

> И как вам такое удаётся ?

Мне? - никак. Я GCC не пользуюсь.

> К примеру gcc для х86_64 генерит SSE2 код по дефолту.

А остальным... ну, я не знаю. Вот вы говорите, что gcc может генерировать SSE2-код. А некто SKYRiDER говорит, что автовекторизация стала возможна только с GCC 4.0. Вы там разберитесь между собой, всё-таки...

Или может, под "генерированием SSE2-кода" вы имеете в виду то, что посредством препроцессора можно узнать, для какой платформы компилируемся, и заюзать написанный вручную для этой платформы код :) ? Ключик "компилируемся под SSE2", который ничего в коде реально не меняет, зато создаёт препроцессорную константу типа GCC_SSE2_ENABLED :))) ? Или даже, может, вы про перплатформенные intrinsic functions :) ?

> Вот вы говорите, что gcc может генерировать SSE2-код. А некто SKYRiDER говорит, что автовекторизация стала возможна только с GCC 4.0.

если я не ошибаюсь, то gcc умеет генерировать sse2 код еще с версии 3.3.*

> если я не ошибаюсь, то gcc умеет генерировать sse2 код еще с версии 3.3.*

А что ВЫ имеете в виду под "уметь генерировать sse2-код"?

(С чувством страшного озарения) Может быть, ПОДДЕРЖКУ АССЕМБЛЕРНЫХ КОМАНД SSE2 В ИНЛАЙН-АССЕМБЛЕРЕ 8-() ?...

ключик -msse2?

только сильно не пинайте

GCC, начиная с версии 3.1, умеет генерить скалярные инструкции SSE/SSE2. Теперь же GCC 4.0 научился сам генерить и векторные инструкции SSE/SSE2 (но не MMX/3DNow!).