LINUX.ORG.RU

GCC 4.9.0 вышел!

 ,


0

4

Спустя один год и один месяц с предыдущего значительного релиза объявлен выпуск новой версии набора компиляторов GNU Compiler Collection 4.9.0.

Список новшеств:

  • Local Register Allocator, представленный в версии 4.8.0 для архитектур ia32 и x86-64, теперь используется также для Aarch64, ARM, S/390 и ARC по умолчанию, а для PowerPC и RX опционально.
  • Существенные улучшения девиртуализации C++, исправлены различные ограничения масштабируемости межпроцедурных оптимизаций и LTO.
  • Во фронтенд C++ была добавлена поддержка различных возможностей будущего стандарта C++14. Наиболее значительное изменение в стандартной библиотеке C++ — поддержка регулярных выражений C++11.
  • GCC 4.9.0 поддерживает стандарт OpenMP 4.0 для C и C++, а также частично реализовано расширение Cilk Plus для параллелизма данных и задач.
  • Различные виды неопределенного поведения (undefined behavior) теперь могут быть диагностированы во время выполнения с помощью Undefined Behavior Sanitizer.
  • Добавлена поддержка новой аппаратной платформы little-endian powerpc64le-linux, по умолчанию для нее используется новый ABI PowerPC ELFV2.
  • Добавлена поддержка набора инструкций AVX-512 на x86-64 и ia32.

>>> Changelog

-march=generic has been retuned for better support of Intel core and AMD Bulldozer architectures. Performance of AMD K7, K8, Intel Pentium-M, and Pentium4 based CPUs is no longer considered important for generic.

Наконец-то.

devl547 ★★★★★ ()

Годно. Как там с чисткой кода?

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

leg0las ★★★★★ ()

изменение в стандартной библиотеке C++ — поддержка регулярных выражений C++11.

не прошло и трех лет

Stil ★★★★★ ()

Ждём стабилизации ебилдов хотя бы 4.8.

O02eg ★★★★★ ()

yay! давно пора.

Undefined Behavior Sanitizer

хм, а оверхэд велик?

wakuwaku ★★★★ ()

Для арма ченджлог вкусный.

ncrmnt ★★★★★ ()

Куда делись все любители шланга-то с криками про ненужно?

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

для Ъ: что это такое, зачем оно нужно, каков профит?

leg0las ★★★★★ ()

GCC 4.9.0 поддерживает стандарт OpenMP 4.0 для C и C++, а также частично реализовано расширение Cilk Plus для параллелизма данных и задач.

Сколько лет прошло, а они все не допилят.

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

Сколько лет прошло, а они все не допилят.

Софта то нет.

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

Ненужно, ко-ко-ко, шланг, тулкит, модульность, библиотеки, BSD, LLVM, эпл.

Доволен? :3

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

неопределенного поведения (undefined behavior) теперь могут быть диагностированы во время выполнения

мы закостыляли костыль в твой костыль, что бы ты мог костылять, пока на костылях.

nanoolinux ★★★★ ()

Поддерживается два метода увеличения производительности - параллелизм данных и параллельное выполнение подпрограмм. В первом случае, обеспечиваются механизмы прозрачного распараллеливания типовых операций над массивами данных и автоматическое задействование SIMD-инструкций. Для организации параллелизма на уровне подпрограмм в обиход вводится три ключевых слова: _Cilk_spawn - запуск функции в параллельном режиме, _Cilk_sync - ожидание завершения параллельно выполняемой функции, и _Cilk_for - организация работы цикла в параллельном режиме.

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

Самое обидное, что только вчера оттуда достал <что-то апрельское>.

DarkAmateur ★★ ()
Последнее исправление: DarkAmateur (всего исправлений: 1)

Эх, а я только на clang переполз (планирую свои ЯП писать на llvm, поэтому передвинулся поближе к нему)

q0tw4 ★★★ ()

так и быть, пересобиру мир. как только появятся ебилды.

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

Недавно вляпался в разименование float* по невыровненному адресу на gcc-4.7 на armv7. Приложение получает SIGBUS (ошибка шины), пофиксили?

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

Так может оно с NEON что-то попыталось сделать, а там требования к выравниванию?

// не шарю в том, как fp устроено на ARM'е

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

Ну я багрепортов не заводил, так что не требую... Пофиксить могли в 4.9, например. Ну может в 4.8.

Сомневаюсь, что *((float*)buf) должно падать, если адрес buf не выровнян по 4-м байтам. Также сомневаюсь, что проблема в железе.

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

-fno-unaligned-access?

Мы сейчас сидим на 4.8.2 плотно.

ncrmnt ★★★★★ ()

Епть, снова @world пересобирать. Гента, такая Гента…

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

-fno-unaligned-access?

Спасибо, попробую. Сейчас нет доступа к проекту.

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

Сомневаюсь, что *((float*)buf) должно падать, если адрес buf не выровнян по 4-м байтам.

Это вообще от железа зависит, чего это компилятор должен в данном случае подтирать задницу кодеру?

mashina ★★★★★ ()

пора на электростанциях учитывать каждый релиз gcc.

punya ★★ ()

Интересно, когда флаг поддержки с++11 будет выставляться по дефолту?

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

Фиксить надо не gcc, а мозг макаке, которая код писала.

Reset ★★★★★ ()

А вы говорите, что clang не нужен. Еще как нужен. Без него gcc перестал бы развиваться.

p.s. Хорошая новость.

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

Сомневаюсь, что *((float*)buf) должно падать, если адрес buf не выровнян по 4-м байтам.

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

andreyu ★★★★★ ()

Когда будет официальная поддержка D? И чето слышно за Go?

eReSik ★★ ()

А когда там выхлоп нормальный обещали?

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

Это вообще от железа зависит, чего это компилятор должен в данном случае подтирать задницу кодеру?

Если бы там NEON какой-нить был, или небезопасные оптимизации, то я бы не возмущался. А тут pure C... В коде-то как раз предусмотрен макрос MAKE_FLOAT для подобных случаев (точнее он задумывался для little-endian/big-endian), так что workaround уложится в пару строк. Но мне кажется, что это баг в компиляторе.

P.S. Если это UB, то можно и нужно ткнуть меня носом в стандарт, но что-то я такие грабли в сишечке не припомню.

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

Но мне кажется, что это баг в компиляторе.

SIGBUS при обращении к неправильно выровненным данным - это баг в куче компиляторов. И его обычно не исправляют %)

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

У clang и gcc совершенно разные применения, они практически не пересекаются.

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

А с какой радости фиксить фичу? Это не баг, так и должно быть.

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

Сомневаюсь, что *((float*)buf) должно падать

Не сомневайся. Должно падать. На множестве платформ, включая SPARC и ARM. Это UB вообще.

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

Если это UB, то можно и нужно ткнуть меня носом в стандарт, но что-то я такие грабли в сишечке не припомню.

Это не UB, это платформенно зависимое поведение, причём на одном и том же железе может быть по разному в зависимости от его конфигурирования. Задача си сделать что написано - разименовать указатель.

но что-то я такие грабли в сишечке не припомню.

Очень странно. Наверное, пишешь мало. Даже на самом либеральном x86 можно нарваться на такое поведение.

mashina ★★★★★ ()

Годно. Традиционно ждём ебилдов...

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