У компилятора баг багу -- рознь. Может быть генерация неверного кода, тогда действительно беда, а может быть генерация неоптимального кода, это хоть и неприятно, но не так страшно.
Дурацкие зеркала у GNU. Отстают сильно. Неужели так сложно cron'ом и rsync'ом сделать поддержание современного состояния? Если бы Linux присоединился к FSF был бы у нас сейчас linux-2.3.4.28.34 на котором X не идут.
Скажите пожалуйста, можно ли собрать систему в такой связке kernel 2.4.20, gcc-3.3.6, glibc-2.3.6 Есть ли проблемы с указанными версиями? Где брать bug-fix патчи для них?
>Скажите пожалуйста, можно ли собрать систему в такой связке kernel 2.4.20, gcc-3.3.6, glibc-2.3.6 Есть ли проблемы с указанными версиями? Где брать bug-fix патчи для них?
Когда-то собирал LFS как раз с glibc-2.3.6 и gcc-3.4.x только ядро было явно новее, что-то около 2.4.30. Вполне нормально собралось, вроде бы и патчей особо никаких не пришлось искать. Больше всего возни со сборкой glibc - там флаги нужно при configure внимательно проставить, чтоб не взумало компилировать всякие NPTL и связаные с ним расширения. Естественно надо не забыть скачать и включить в исходники glibc-linuxthreads addon :)
--21:55:27-- http://linux01.gwdg.de/~nlissne/deltup.php?have=libwpd-0.7.2.tar.gz&want=...
=> `deltup.php?have=libwpd-0.7.2.tar.gz&want=libwpd-0.8.2.tar.gz&url=http:% 2F%2Fkeihanna.dl.sourceforge.net%2Fsourceforge%2Flibwpd%2Flibwpd-0.8.2.tar.gz&am p;version=0.7&time=1148583327'
Распознаётся linux01.gwdg.de... 134.76.13.21
Устанавливается соединение с linux01.gwdg.de|134.76.13.21|:80... соединение установлено.
Запрос HTTP послан, ожидается ответ... 302 Found
Адрес: http://134.76.13.21/~nlissne/deltas/libwpd-0.7.2.tar.gz-libwpd-0.8.2.tar.gz.dtu [переход]
--21:55:30-- http://134.76.13.21/~nlissne/deltas/libwpd-0.7.2.tar.gz-libwpd-0.8.2.tar.gz.dtu
=> `libwpd-0.7.2.tar.gz-libwpd-0.8.2.tar.gz.dtu'
Повторное использование соединения с linux01.gwdg.de:80.
Запрос HTTP послан, ожидается ответ... 404 Not Found
21:55:31 ОШИБКА 404: Not Found.
И так со всеми файлами! Так шта не надо тут демагогию разводить!
Частный случай оптимизации - 4.1.0 не хватило регистра процессора для прокрутки этого тупого цикла. Добавьте в цикл еще чего-нибудь, и тогда регистра не хватит и 4.0 - тогда скорее всего скорости сравняются. А то и в пользу 4.1 - как показали в багтраке на последнем примере. Так что на реальных задачах шут его знает что выдаст лучший код - 4.0 или 4.1.
А баг - пусть вылечат, может где-нибудь в 1 проценте кода и появляются такие куски где срабаьтывает эта недостаточная оптимизация.
Кстати основное что нужно вынести из этого бага в генту - собирать с O3. В этом случае все оптимизации включаются.
К сожалению (на примере анекдотов на С) некоторые приложения с O3 компилировать противопоказано. Причём никогда не знаешь наперёд, где именно этот анекдот вылезет.
Анонимусу выше:
Приведите пример хотя бы одного реального приложения, где от этого бага пострадала суммарная производительность в два раза, тест демонстрирующий регрессию не считается.
Поищите топик (известный здесь как "Анекдоты на C"), где Алфекс объясняет код своего парсера. Там был пример, с инкрементами, который давал разный результат при -O2 и -O3 с gcc, причём его гоняли потом под разные платформы и разными компиляторами. Если сейчас найду, то дам ссылку, если нет извините.