Jakub Jelinek, разработчик из компании Red Hat, анонсировал (http://gcc.gnu.org/ml/gcc/2013-03/msg00127.html) первый кандидат в релизы набора компиляторов GCC 4.8. Если не возникнет непредвиденных проблем, финальный релиз ожидается в конце недели.
Наиболее видными изменениями станут:
- Новый уровень оптимизации "-Og", нацеленный на то, чтобы сделать отладку более удобным и приятным процессом. В данном режиме сокращается время компиляции, а компилятор производит только минимальные оптимизации не влияющие на результаты при отладке;- Ряд улучшений в оптимизациях при генерации кода.
- Серия улучшений в поддержке архитектуры ARM.
- * Поддержка новых чипов семейства Intel Haswell, а также AMD Jaguar и Steamroller.
- Реализация (http://www.phoronix.com/scan.php?page=news_item&px=MTIzOTU) Address Sanitizer (-fsanitize=address) и Thread Sanitizer (-fsanitize=thread):
- Address Sanitizer - средство выявления некорректных обращений к памяти. С его помощью можно выявлять обращения к областям памяти после их освобождение ("use-after-free"), разрушение кучи, стека, а также переполнения буферов. Использование Address Sanitizer может замедлить работу программы примерно в два раза.- Thread Sanitizer - режим обнаружения состояния "гонок" при совместном доступе к одним и тем же данным из различных тредов. Thread Sanitizer базируется на коде из программы Valgrind. Использование Thread Sanitizer может очень сильно (~в 10 раз) замедлить работу программы.
- Улучшения в поддержке стандартов C++11 и C11, а также реализация ряда возможностей будущего стандарта C++1y.
- Кодовая база компилятора переведена на использование языка C++.
URL: http://gcc.gnu.org/ml/gcc/2013-03/msg00127.html
Новость: http://www.opennet.me/opennews/art.shtml?num=36420
> отладку более удобным и приятным процессом.GDB - Теперь банановый!!!
Вдуй по самые регистры - установи GCC 4.8!!! :-*
вы таки что-то имеете против приятных процессов?
> вы таки что-то имеете против приятных процессов?Нет, наша партия исключительно, только за приятные процессы. (треды наслаждений, форки страсти, и планировщик удовольствия)
Вот он, карго культ. К берегам россии волны океана принесли нечто непонятное. Жители обсуждают - какой у него цвет и вкус, можно ли отпилить кусочек и смастерить блестящую пуговицу. Не, я конечно ни ожидал откровений вроде "как здорово, теперь можно повысить разрешающую способность нашего томографа, код стал быстрее, картинка обновляется практически в реальном времени и благодаря этому диагностика заболеваний стала проще". Но ерничать над словами это уже кранты.
Это Опеннет, тут уже лет 10 никто по делу не пишет. Вот когда забанят анонимные логины,
сделают авторизацию с подтверждением личности, ридонли на три месяца, тогда Опеннет станет
профессиональный сайт. А так, флудезный срачь на тему опенсорса.Вон чуть выше смотри, свежую новость про PHP, сейчас там такая говнодавка начнётся...
Модераторы отлично работают трут Комменты по делу и нет.
> Модераторы отлично работают трут Комменты по делу и нет.
Ага, только нынешние регистрации обнулить, все заново, и ридонли на три месяца :)
> Ага, только нынешние регистрации обнулить, все заново, и ридонли на три месяца :)Нафига? Мамонты сами редко чего пишут, отвечают по-настроению, поиском пользоваться умеют.
> Нафига? Мамонты сами редко чего пишут, отвечают по-настроению, поиском пользоваться умеют.Засчитать за такое только тех у кого 15+ публикаций, т.к. делом доказали что могут приносить пользу ресурсу. А гражданам-пустозвонов с "публикации отсутствуют" - навесить штраф относительно анонимусов, ибо делом доказали что пустозвоны.
> Вот когда забанят анонимные логиныСвежо предание. Интересно, существуют ли вообще ресурсы, которым это сильно помогло.
> сделают авторизацию с подтверждением личности, ридонли на три месяца, тогда Опеннет станет
профессиональный сайт.
Длинный синоним для "никогда" получился. Пессимистично.
Смотря как оценивать "помогло". На кладбище, например, обычно тишина и порядок. Если на него ориентироваться...
Но, постоянно читая неграмотные и неумные комментарии людей, не считающих необходимым подписаться под своими словами, невозможно не начать относиться к любому незарегистрированному пользователю априори негативно. Так что перманентная "свежесть предания" обеспечена.
> априори негативно. Так что перманентная "свежесть предания" обеспечена.Достаточно иногда смотреть кто пишет новости и негатив нейтрализуется позитивом, ради которого вы приходите на ресурс. Хотя балаболов в целом намного больше, вы правы. Только если некто зарегал ник - это не делает его лучше автоматически. Поэтому процент флудеров и балалолов среди зареганых ников - примерно такой же. Просто в силу разных ников - меньше в глаза бросается. Единственное отличие :).
Есть нюанс. Часто пишущие зарегистрированные всем знакомы, и все знают, чего от них ожидать. Известный здесь человек может быть лапидарен до грубости и заносчив, но если он обычно говорит по делу, вы принимаете его таким, какой он есть.
Анониму в этой уступке отказано. Пост анонима по умолчанию не воспринимается как мнение человека, знающего, зачем нужно открывать рот. А словесные поллюции от подростков с гормональным уринозом лобных долей только укрепляют это предубеждение.
Ник на форуме — не оффлайновая подпись, которую обычно имеют в виду. Ну будет вам ясно, что те два сообщения написаны одним человеком, а не двумя, что тут это кардинально поменяет? Легкость бана-игнора, пусть.
К предвзятости, имхо регистрация на это тоже мало влияет. Отфильтровываются наиболее нерелевантные личности, которым возможность оставить нецензурщину привлекательна уже сама по себе, но одно это ведь не делает всё остальное ценным. Возможность зарегистроваться и постить нерелевантный контент тоннами остается.Как побочный пример, на том же лоре после последнего бана анонимусов кое-кто ушел потому, что dev-раздел зацепило тоже. И люди среди них были разные.
>Вон чуть выше смотри, свежую новость про PHP, сейчас там такая говнодавка начнётся...Да сейчас сюдя BSD-шлангеры подтянутся - здесь будет срача и говна намного больше.
> тогда Опеннет станет...безжизненной пустыней :)
>> тогда Опеннет станет
> ...безжизненной пустыней :)А бурлящие г@вна хоть кому-то здесь сделали хорошо?
> А бурлящие г@вна хоть кому-то здесь сделали хорошо?мне, например.
> Использование Address Sanitizer может замедлить работу программы примерно в два раза.
> Использование Thread Sanitizer может очень сильно (~в 10 раз) замедлить работу программы.Ради этого, собственно, эти фичи и были придуманы. Судя по новости.
> Ради этого, собственно, эти фичи и были придуманы. Судя по новости.Вы-таки хотите улучшить эти фичи или эту новость?
Мойша, таки новость. Но не знаю, как.
> Но не знаю, как.http://www.opennet.me/opennews/art.shtml?num=36420 -> "исправить" под текстом
Хотите сказать, что java и js уже достаточно тормозны, добрались до плюсов?)
В известных мне системах системах, код на java и js всегда будут тормознее кода на c++, при наличии разумного программиста.
> В известных мне системах системах, код на java и js всегда будут
> тормознее кода на c++, при наличии разумного программиста.Там вверху разумные программисты gcc/gxx работают над этой Ж) "проблемой".
> Там вверху разумные программисты gcc/gxx работают над этой Ж) "проблемой".Знаете чем отличается сишный програмер от скрипткидиса? Сишный програмер сам выбирает какие из фич и загородок расставить. Скрипткидя ставят в стойло пинками, а изменить расстановку загородок в загоне кидь не может даже если сильно приспичило. Вот за что-то такое мы и называем это явление быдлокодерами.
интересно, Столлман не стал возмущаться по поводу того, что код GCC переписывается на плюсах?
Я где-то слышал, что изначально GCC был написан таким образом, чтобы его правка/дополнение стало нетривиальной задачей.
Нет с архитектурой там гуд, просто компилятор вообще сложная штука, и чтобы чето дополнять до хрена времени нужно убить.
> правка/дополнение стало нетривиальной задачей.Это хорошо - до финиша доезжают только лучшие. А кидисы идут колупать свои скрипты, где пакостить и ломать все подряд, включая интерпретер - просто.
Сижу на svn версии, слежу за поддержкой ARM. Из не приятных изменений можно отметить лишь увеличение времени компиляции. И до сих пор не могут победить одну проблему, при которой компилятор не пользуется stm* ldm* инструкции для работы с памятью(можно гурзить/заганять из/в памят{и,ь} несколько регистров за одну инструкцию). clang в этом плане более продвинут, но в остальном неплохо просерает gcc.
> Сижу на svn версии, слежу за поддержкой ARM. Из не приятных изменений
> можно отметить лишь увеличение времени компиляции. И до сих пор не
> могут победить одну проблему, при которой компилятор не пользуется stm* ldm*
> инструкции для работы с памятью(можно гурзить/заганять из/в памят{и,ь} несколько регистров
> за одну инструкцию). clang в этом плане более продвинут, но в
> остальном неплохо просерает gcc.Загрузкой/загонкой в память занимается ядро: sys_mmap/sys_munmap.
Поэтому, если ваша кунг-фу достигла уровня регистров, то пора
писать свои memcpy/memset на ассемблере под АРМ
; memory copy with preload
ALIGN
LEAF_ENTRY my_memcpy
PLD [r1, #0xC0]
VLDM r1!,{d0-d7} ;datatype misalignment
VSTM r0!,{d0-d7}
SUBS r2,r2,#0x40
MOV R0, #0
MOV PC, LR
ENTRY_END---
...size_t size = /* arbitrary */;
size_t offset = 1;
char* src = new char[ size + offset ];
char* dst = new char[ size ];my_memcpy( dst, src + offset, size );
Понимаете, memcpy, memset уже и без вас давно написаны, на ассемблере, да. Но когда компилятор заполняя параметрами стек, делает это через кучу str, а не через один stmia, тут уже теряются драгоценные такты. Это лишь один из примеров.
> Понимаете, memcpy, memset уже и без вас давно написаны, на ассемблере, да.
> Но когда компилятор заполняя параметрами стек, делает это через кучу str,
> а не через один stmia, тут уже теряются драгоценные такты. Это
> лишь один из примеров.Чёй-та я не вдуплю, компилятор плохой, или код генерит плохой?
Объясняю ещё раз, в gcc имеется баг, который препятствует данной оптимизации.
> Объясняю ещё раз, в gcc имеется баг, который препятствует данной оптимизации.Еще раз объясню, gcc - это компилятор. memcpy() на асме, можно реализовать,
из известных мне, 8 способами MMX, SSE, SSE2, SSE3, SSE4, FPU, SSE+CPU
ни них самый быстрый - это MMX+CPU и пару PREFETCH команд.
Пля, GCC это не умеет, БАГА БАГА БАГА!!!!Ах да, открою для вас тайну - GCC не предсказывает будущие!
Говорю же, если считаешь что познал нирвану - пиши вставки на асме.Это судьба архитектуры ARM :D
Ты наркоман, или прикидываешься? Я где нибудь писал про memcpy? Речь идёт о инструкциях stm*/ldm*. Кури матчасть.> Ах да, открою для вас тайну - GCC не предсказывает будущие!
Я хочу вас огорчить... Но гцц предсказывает будущее. Можете почитать про оптимизатор.
1) откройте для себя intrinsics
2) самый бестрый - mmx + программная предзагрузка, т.к. prefetch это лишь hint и его фактическое исполнение не гарантируется
> 2) самый бестрый - mmxИ где у ARMов находится MMX?
Я отвечал на конкретный пост, а не утверждал что-то про ARM
павлин, ну при чём тут memcpy? O_O речь-то о том, что компилятор не умеет несколько регистров одной инструкцией в память совать. как выше сказано — при передаче параметров на стеке это было бы шустрее, чем по одному запихивать, например.
> ALIGN
> LEAF_ENTRY my_memcpy
> PLD [r1, #0xC0]
> VLDM r1!,{d0-d7} ;datatype misalignment
> VSTM r0!,{d0-d7}
> SUBS r2,r2,#0x40
> MOV R0, #0
> MOV PC, LR
> ENTRY_ENDНезнакомые инструкции.. Так лень учить ARM? :(
> Незнакомые инструкции.. Так лень учить ARM? :(Случайно "?" поставил. Там подразумевалась ".".
Надо будет собрать порт lang/clang-devel (clang-devel 3.3.r176188) этим вашим GCC 4.8.0.20130310 (порт lang/gcc48), в свою очередь собранным системным LLVM/Clang 3.2. А потом собрать www/chromium и тем, и другим, и третьим компилятором и протестировать быстродействие. Ж)
> Надо будет собрать порт lang/clang-devel (clang-devel 3.3.r176188) этим вашим GCC 4.8.0.20130310
> (порт lang/gcc48), в свою очередь собранным системным LLVM/Clang 3.2. А потом
> собрать www/chromium и тем, и другим, и третьим компилятором и протестировать
> быстродействие. Ж)Это даст +100500 к карме!
Характеристики программы, собранной компилятором, не зависят от того, каким компилятором собрали компилятор. Может повлиять только на скорость сборки.
Малышь ... когда нибудь и ты столкнешься с компиляторами, по настоящему. А там всё не совсем как в книжках пишут ... :(
Премудрый пескарь, компиляторы сначала собирают себя, а потом собой ещё раз себя. Нет разницы, чем был изначальный компилятор - хоть tcc, хоть шланг.
ты сам-то хоть знаешь?
>Малышьнет, скорее всего
> Малышь ... когда нибудь и ты столкнешься с компиляторами, по настоящему. А
> там всё не совсем как в книжках пишут ... :(Ага, щас. Компилятор влияет только на эффективность выполнения кода, сами исходники он менять не будет. А значит компилятор будет делать то, что у него в исходниках, а не то, что в исходниках компилятора, его собравшего. Так что разницы не будет, может компилироваться только по-быстрее будет. На бинарь на выходе оно не повлияет.
> МалышьПередайте привет вашему учителю русского языка.
> ... когда нибудь и ты столкнешься с компиляторами, по настоящему. А
> там всё не совсем как в книжках пишут ... :(Если компилятор меняет логику работы программы (т.е. другого компилятора) - это хреновый, бажный компилятор, которому место на свалке. Компилить таким компилятором что либо ни в коем случае нельзя.
> Надо будет собрать порт lang/clang-devel (clang-devel 3.3.r176188) этим вашим GCC 4.8.0.20130310
> (порт lang/gcc48), в свою очередь собранным системным LLVM/Clang 3.2. А потом
> собрать www/chromium и тем, и другим, и третьим компилятором и протестировать
> быстродействие. Ж)ЭТО ПРОВАЛ
///---
% portmaster www/chromium
┌─────────────────────── chromium-25.0.1364.172 ─────────────────────────┐
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ [ ] CLANG Build Chromium with Clang instead of GCC 4.6+ │ │
│ │ [x] CODECS Compile and enable patented codecs like H.264 │ │
│ │ [ ] DEBUG Install debug symbols │ │
│ │ [x] GCONF GConf configuration backend │ │
│ │ [ ] PULSEAUDIO PulseAudio sound server │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────┤
│ < OK > <Cancel> │
└────────────────────────────────────────────────────────────────────────┘
...
...
...
./base/bind.h:497:18: warning: typedef 'p6_is_refcounted_type_and_needs_scoped_refptr' locally defined but not used [-Wunused-local-typedefs]
p6_is_refcounted_type_and_needs_scoped_refptr);
^
./base/basictypes.h:206:39: note: in definition of macro 'COMPILE_ASSERT'
typedef CompileAssert<(bool(expr))> msg[bool(expr) ? 1 : -1]
^
./base/bind.h:499:18: warning: typedef 'p7_is_refcounted_type_and_needs_scoped_refptr' locally defined but not used [-Wunused-local-typedefs]
p7_is_refcounted_type_and_needs_scoped_refptr);
^
./base/basictypes.h:206:39: note: in definition of macro 'COMPILE_ASSERT'
typedef CompileAssert<(bool(expr))> msg[bool(expr) ? 1 : -1]
^
gmake: *** [out/Release/obj.target/notifier/jingle/notifier/base/weak_xmpp_client.o] Ошибка 1
gmake: *** [out/Release/obj.target/notifier/jingle/notifier/communicator/connection_settings.o] Ошибка 1
./base/observer_list_threadsafe.h: In constructor 'UnboundMethod<T, Method, Params>::UnboundMethod(Method, const Params&)':
./base/observer_list_threadsafe.h:66:9: warning: typedef 'badunboundmethodparams' locally defined but not used [-Wunused-local-typedefs]
badunboundmethodparams);
^
./base/basictypes.h:206:39: note: in definition of macro 'COMPILE_ASSERT'
typedef CompileAssert<(bool(expr))> msg[bool(expr) ? 1 : -1]
^
*** [do-build] Error code 1Stop in /usr/ports/www/chromium.
*** [build] Error code 1Stop in /usr/ports/www/chromium.
===>>> make failed for www/chromium
===>>> Aborting updateTerminated
% pkg_info -Ex gcc
gcc-4.8.0.20130310
---///Chromium не собирается GCC 4.8.0.
да, изя, это очередной твой провал. ты же не пошёл на сайт gcc, не стал читать замечания к релизу. а там открытым текстом, без шифрования и системы паролей написано про новые warnings, и к чему это может привести. и как это временно отключить, пока авторы эти warnings не устранят.но ведь читать — это мозг нужен, сложно, не так ли, изя? то ли дело с шашкой, да сразу на танк.
> да, изя, это очередной твой провал. ты же не пошёл на сайт
> gcc, не стал читать замечания к релизу. а там открытым текстом,
> без шифрования и системы паролей написано про новые warnings, и к
> чему это может привести. и как это временно отключить, пока авторы
> эти warnings не устранят.
> но ведь читать — это мозг нужен, сложно, не так ли, изя?
> то ли дело с шашкой, да сразу на танк.Усира, порты не я придумал. Способ сборки chromium с помощью GCC 4.6+ не я прописываю в инструкциях make.
изя, если бы ты мог что-то полезное придумать… или хотя бы понять, что gcc 4.8 ещё нет, и совместимость с ним пока что никто обеспечивать не должен. а если некий изя решил на свой страх и риск попробовать — то пусть сам потрудится. но ты же просто сказочно туп, фантастически.
Ияз, твой тупняк уже не смешной, даже не забавный.
> Реализация Address SanitizerЯ правильно понимаю что оно просто добавляет в код дополнительные проверки и информацию которая для них необходима, и получается типа самотестирующийся бинарник, которому не нужны никакие внешние valgrind/gdb? Если так то очень здорово.
Есть тесты скорости сборки программ 4.8 vs 4.7?
Зачем? Ну правда?
Это такая беда, что компиляция будет идти на 5% дольше, что ради этого нужно портить себе нервы?Ждите тестов хороникса, они покажут ))
>Это такая беда, что компиляция будет идти на 5% дольше, что ради этого нужно портить себе нервы?Ну вообще да, беда. Не на 5% конечно, но 10-20% уже существенно. Когда занимаешься разработкой. Например, у нас в конторе хоть размеры проектов и не велики (под микроконтроллеры пишем), зато конфигураций 100500, поэтому ждать пока всё на Hudson'e собирётся часто надоедает.
Это решается адекватной модульностью. Никогда не нужно пересобирать всё сразу, повторяю: никогда.
> Это решается адекватной модульностью. Никогда не нужно пересобирать всё сразу, повторяю:
> никогда.Это так-то решается адекватным config management. Что, ваш софт разработки это не умеет? в 2013м году?
> Никогда не нужно пересобирать всё сразу, повторяю: никогда.you are terribly wrong, my dear. да будет тебе известно: clean build — очень полезная практика. с опытом поймёшь.
Попробуйте собирать параллельно.
> Попробуйте собирать параллельно.Это не отменяет того факта что в плюс к этому добавочное ускорение сборки "тестового" билда - это хорошо.
> Есть тесты скорости сборки программ 4.8 vs 4.7?Да. Фороникс не был бы форониксом если бы они смогли пройти мимо плюшки без бенчмарка: http://www.phoronix.com/scan.php?page=article&item=gcc_48_og...
> Серия улучшений в поддержке архитектуры ARMнеужели линаровские наработки?
Вот оно - положительное влияние clang.
> Вот оно — положительное влияние clang.где? по пунктам можно? с доказательствами.
я пока что нашёл только идиотическое «подчёркивание» места ошибки, которое приходится с матюгами выключать.
Вторая и четвертая кругленькая черная точечка в новости.
> Вторая и четвертая кругленькая черная точечка в новости.я же сказал: с доказательствами того, что без шланга никак бы не было. пока что я их не вижу.
Товарищ, не переживайте. clang указал на слабые места гнутого связанные с отладкой. У разработчиков появился еще один стимул что-то подправить по-возможности. На мой взгляд, новость это только подтверждает.>с доказательствами того, что без шланга никак бы не было.
А почему я должен доказывать _Ваши_ измышления. Как-нибудь вполне было бы и без шланга.
не мои, а свои. я, впрочем, на это и не рассчитывал.