25 лет GCC и выпуск 4.7.0

И она таки у тебя проинсталлирована на боевой машине, Федора-то семнадцатая? Нет? ;)

подсказать какой компилятор используется в Xcode или сам догадаешься?

Десятая версия ещё собиралась, а вот 11 уже нет. Если не трудно намекни, какой конкретно абзац из man ld читать?

зОчем? оО

Это на счет поддержки арм.

таки умеет ARM? спасибо. не знал.

Я уже молчу про OpenJDK Shark, цель которого перенос Java JIT на другие платформы без написания ассемблерного кода.

Ну смотря что считать «боевой» машиной. Пре-бета уже у достаточно многих на домашних компах стоит.

Суть в том, что хотя релиз gcc4.7 это конечно новость, но работают с ним, пересобирают с нуля всю систему и массово фиксят баги уже достаточно давно. И сейчас-то (в отличии от первой массовой пересборки в декабре) там всё в нормальном рабочем состоянии.

--no-keep-memory

Мне нужен кросскомпилятор ады под АРМ, есть такой?

В начале был компилятор и компилятор был Гыцыцы.

и компилятор был Pastel, Pastel родил gcc, gcc родил clang, clang родил...

и как он - уже все собирает нормально?

TI's C6X

P_P

Поддержка транзакционной памяти на некоторых архитектурах

чо это такое? :)

и компилятор был Pastel, Pastel родил gcc, gcc родил clang, clang родил...

Ну все у вас через пастэль, сплошной разврат а не open source.

спасибо, пойду канпилять о.О ;)

Ну все у вас через пастэль, сплошной разврат а не open source.

пастэль тоже был open source ;) и да - не у вас, а у нас

чо это такое? :)

для кого википедию придумали? :)

http://en.wikipedia.org/wiki/Transactional_memory

Кстати неправда!

Stallman

В надежде избежать разработки компилятора целиком, я раздобыл исходники компилятора Pastel, многоплатформного компилятора, разработанного Lawrence Livermore Lab. Он поддерживал (и сам был написан) расширенный диалект языка Pascal, предназначенный для системного программирования. Я добавил в него поддержку C, и начал переносить его на Motorola 68000. Но мне пришлось отказаться от этого, когда я обнаружил, что компилятору требуются мегабайты под стек, в то время, как доступная на 68000 Unix-система ограничивается лишь 64k.

Оказалось, что компилятор Pastel сначала строил по всему входному файлу дерево разбора, далее конвертировал его в цепочку «инструкций», а затем генерировал целиком выходной файл, вовсе не освобождая памяти. На этом этапе я заключил, что все-таки придется написать новый компилятор с самого начала. Новый компилятор известен сегодня как GCC; никакие части Pastel в нем не использованы, но мне довелось адаптировать и использовать уже написанный мной код поддержки C. Но все это случилось несколькими годами позднее, а в то время я работал над GNU Emacs.

источник

не нужно же, ведь скоро выйдет Visual C++ 2011, с параллельным преобразователем программ.

Кстати неправда!

я ж не сказал, что gcc был форком pastel, он им был собран

Улучшение оптимизации во время компоновки (Link Time Optimization).

Систему уже собрать можно?

Годно, особенно потому что почти допилили C++11.

Ведро соберет?

clang сейчас играет догоняющего

хех федорка 17 будет пересобрана gcc 4.7.0 уж и не думал, что кто-то может обогнать генту в плане новых версий )

А ты откуда гцц4.7 брал? Ебилдов еще нет (в оверлаях не проверял). Или сам писал?

Ждем ебилдов.

Было бы неплохо добавить ссылку http://gcc.gnu.org/gcc-4.7/cxx0x_status.html если речь пошла о C++11

А в генте до сих пор 4.6 хардмаскед. Печаль.

кстати, если говорить про поддержку в дистрибутивах, то в debian/ubuntu 4.7 уже недели три доступен

и какие же архитектуры поддерживают STM? и стоит ли писать с помощью этой штуки, ведь код будет непортабельным если это хотя бы не эмулируется вообще на всех архитектурах

Компилятор №1, long live!!

и какие же архитектуры поддерживают STM?

ты наверное имел ввиду HTM - там все написано

и стоит ли писать с помощью этой штуки

в IBM же не дураки работают, стоит конечно

параллельным преобразователем программ

во что?

если все-таки STM - то x86, Sparc и пр. подходят

лучше бы сoncurrency активней пилили

emerge =sys-devel/gcc-4.7.0

layman -a toolchain

теперь я смогу собрать ff с pgo на моих 4Гб Ram и 4Gb swap и oom-killer не будет убивать кеды и весь остальной прикладной софт :)

Толсто. OOM-killer убивает процесс с наибольшим score и таким будет тот, что больше сожрал. Не верю, что кеды сожрут больше, чем gcc с ld.

ацтой - 25 лет проекту и всего 4.7.0, файерфокс через 25 лет будет(?) уже 200 (да-да, двухсотой) версии - вот это я понимаю.

# eix -I udev
[I] sys-fs/udev
     Available versions:  114 115-r1 119 124-r1 124-r2 141 ~141-r1 146-r1!t 149 151-r4 164-r2 171-r5 ~181 **9999!u {acl action_modeswitch build debug (+)devfs-compat doc edd (-)extras floppy gudev hwdb introspection keymap old-hd-rules +rule_generator selinux static-libs test}
     Installed versions:  171-r5(01:31:31 21.03.2012)(acl extras gudev hwdb keymap rule_generator -action_modeswitch -build -debug -edd -floppy -introspection -selinux -test)
     Homepage:            http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

Удев моложе фаерфокса и то на порядок опередил его по номеру версии — вот это я понимаю.

у меня да -_- ну не совсем на боевой я там по порносайтам тока лажу и в оилрашь режусь.

в генте вообщето гцц весьма слоупочно появляется. и да федоровский равхайд старается использовать самый что не на есть свежак.

ээ в оверлеях в официальных портах он появится нескоро а размаскируют его и того гляди через год.

видать это из-за того, что много софта(около тысячи из 11270) не собирается из-за переходя на новую версию, видать гентушники боятся этого

в общем только закончил компилировать(неудачно) ff с pgo с флагом --no-keep-memory. В итоге внимательно присмотрелся и вот что обнаружил. Система упирается в ограничение памяти при линковке. Ошибка где-то в скрипте сборки, потому что к этому времени линковка уже закончена и запускается 11580(!) одинаковых процессов make clean. После того как swap наполняется на половину даже мышью двигать невозможно. Переключение на tty1 длится 2 минуты. После этого можно долго смотреть на экран и раз в 15 секунд видно как кол-во процессов растёт. А потом вот:

Mar 22 19:21:51 localhost kernel: [23472.926658] [16012]  1000 16012     1486      
 15   3       0             0 sh
Mar 22 19:21:51 localhost kernel: [23472.926661] Out of memory: Kill process 802 (p
lasma-desktop) score 11 or sacrifice child
Mar 22 19:21:51 localhost kernel: [23472.926681] Killed process 805 (ksysguardd) total-vm:9776kB, anon-rss:176kB, file-rss:8kB
Mar 22 19:25:40 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset

Так что это был не вброс вовсе и в моём случае первыми отстреливаются «кеды», но легче от этого не становится - по прежнему нельзя ничего сделать с компьютером. В данном случае я нажал reset, т.к. ждать надоело. Но со временем oom-killer «убивает» всё до чего дотягивается. В итоге живые процессы занимают всего 150 Мб памяти. Такие дела.

запускается 11580(!) одинаковых процессов make clean

Это что-то странное. Если так, то действительно убьются кеды, потому что каждый make жрёт мало.

У меня же OOM-killer убивал именно ld, когда ему не хватало памяти. Себе в LDFLAGS уже добавил --no-keep-memory, посмотрю, как подействует.

И да, это точно make clean? Я не знаю, что именно чистит make clean у фаерфокса, но вообще-то его можно не запускать вообще, если это стандартный clean, который удаляет всё, что создалось после сборки. И в ебилде я не нашёл, где он запускается.

посмотрю, как подействует

линковка замедлится // кэп

линковка замедлится // кэп

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

В предыдущем посте, я пропустил «не». Когда выполняется линковка, памяти расходуется только 3 Гб. После этого в течении получаса можно работать за компьютером и наблюдать совершенно одинаковые процессы типа

cd /tmp/каталог_сборки/firefox_что-то-там/ ; make clean

У меня не генту, а арч. Похоже скрипт генту написан правильно в отличии от того, который в арче.