GCC 4.9.0 вышел!

-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.

Наконец-то.

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

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

Я жду deb'ов. OpenMP 4.0 мням-мням))

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

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

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

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

Undefined Behavior Sanitizer

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

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

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

Ща придут.

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

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

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

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

Софта то нет.

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

Доволен? :3

В Sid уже есть.

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

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

Доволен? :3

Да :3

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

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

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

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

Не ты один)

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

Пофиксили где?

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

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

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

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

ненужно!!1

-fno-unaligned-access?

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

В Sid уже есть.

а вот и нет https://packages.debian.org/search?keywords=gcc

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

-fno-unaligned-access?

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

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

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

Им, наверное, всё-таки время нужно для сборки пакета.

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

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

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

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

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

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

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

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

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

а вот и нет

https://packages.debian.org/search?suite=sid&keywords=gcc

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

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

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

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

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

И чето слышно за Go?

Поддержка языка Go 1.2.1 реализована.

sudo cast Sylvia

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

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

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

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

И? А gcc-4.9 не пробовали искать?

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

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

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

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

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