LINUX.ORG.RU

GCC 6.1

 , ,


2

5

Состоялся релиз GCC 6.1 — набора свободных компиляторов с открытым исходным кодом. Основным новшеством стало применением в компиляторе C++ по умолчанию стандарта C++14 и улучшение экспериментальной поддержки C++17. Кроме того расширены средства диагностики, заявлена полная совместимость с OpenMP 4.5 и поддержка системной библиотеки musl. Также заявлено об улучшении поддержки платформ ARM и поддержке процессоров AMD Zen, Intel Skylake, IBM z13 и IBM POWER 9.

Основные изменения:

  • Активировано по умолчанию для языка C++ использование стандарта C++14 (применяется режим -std=gnu++14 вместо -std=gnu++98). Кроме того добавлена поддержка расширения системы шаблонов C++ Concepts, активируемая опцией -fconcepts. Реализованы некоторые новые элементы будущего стандарта C++17, такие как выражения fold, символьные литералы u8, расширенный static_assert и вложенное определение пространств имён. Реализована возможность вычисления констант для всех бестиповых аргументов шаблонов. Добавлена поддержка транзакционной памяти (C++ Transactional Memory) при сборке с опцией -fgnu-tm;
  • Для runtime-библиотеки libstdc++ расширен набор специальных математических функций (ISO/IEC 29124:2010), добавлена экспериментальная поддержка стандарта C++17 (в том числе новые функции std::size, std::empty, std::data для контейнеров и массивов, std::uncaught_exceptions, std::invoke, std::shared_mutex, std::void_t и std::bool_constant), экспериментальная поддержка File System TS, экспериментальная поддержка второй версии Library Fundamentals TS, поддержка std::locale для DragonFly и FreeBSD;
  • Появилась поддержка Си-библиотеки musl, которую можно использовать на Linux-системах с архитектурой AArch64, ARM, MicroBlaze, MIPS, MIPS64, PowerPC, PowerPC64, SH, i386, x32 и x86_64. Поддержка включается опцией -mmusl или при выборе архитектуры по маске *-linux-musl*.

>>> Подробности (на английском языке)

★★★★★

Проверено: Klymedy ()

Ответ на: комментарий от FilosofeM

Работает быстрее, код генерирует более эффективный... Блин, да GCC тупо всем лучше Clang...

Stahl ★★☆ ()

Интересно, что они понимают под термином Transactional Memory? Когда работаешь с STM, то основной прием - это подготовить будущие операции IO, которые потом выполняются за пределами атомарной транзакции. А как с этим быть на Си++?!

dave ★★★★★ ()

Что подразумевается под поддержкой musl? Он включен в поставку с компилятором? На любой системе с gcc6 можно будет скомпилировать бинарник с musl?

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

Год назад был, теперь раз в год меняется первое число в номере версии.

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

Лишь бы за цифрами угнаться.

Впрочем, не так уж и плохо.

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

4.2, скорость компиляции у шланга выше. Насчёт качества кода для armv64 я бы тоже поспорил.

anonymous ()

Активировано по умолчанию для языка C++ использование стандарта C++14

Ну наконец-то

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

Настало время вбрасывать аргументы более весомые чем собственное мнение.

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

скорость компиляции у шланга выше

Это было в те времена, когда Clang генерировал какую-то муть, а не код. Даже тут на ЛОРе кто-то размазывал сопли, что последние версии медленней, чем GCC.

Stahl ★★☆ ()

musl это интересно, альтернативы это всегда хорошо.

Bfgeshka ★★★★★ ()

zen же ещё не выпустили, блджд. Торопыги. А потом выйдет камень с другими инструкциями и будут править? Охрененно.

darkenshvein ★★★★★ ()

Объясните мне, что там за драма с переписыванием gcc на C++?

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

Если так, то когда ожидать закапывания?

shkolnick-kun ★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

Ну так эмулятор-то, наверно, есть...

Да и команда разработчиков процессора наверняка причастна к gcc-шному бэкэнду, ибо выпускать проц без средств разработки в наше время - деньги на ветер...

shkolnick-kun ★★★ ()
Ответ на: комментарий от darkenshvein

zen же ещё не выпустили, блджд. Торопыги.

Что это, зачем нужно и с какого они должны задерживать релиз из-за этого?

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

аа, ну так то да. в практике выпуске железа я не силён.

darkenshvein ★★★★★ ()
Ответ на: комментарий от shkolnick-kun

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

Что за бред? В чём проблема открыть код и разобраться во внутренностях? Пока gcc кому-то нужен, будут и люди, которые его поддерживают. Тем более, что основная масса пользователей gcc всё-таки умеют программировать.

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

Насчёт качества кода для armv64 я бы тоже поспорил.

конечно - ведь такой процессорной архитектуры не существует.

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

Что за бред? В чём проблема открыть код и разобраться во внутренностях?

Смешно. Люди в языке C++ разобраться не могут, а о том что бы разобраться как он компилируется, это надо людей закрывать в помещении и приносить им еду, не выпускать пока не разберутся. Но так как это пока запрещено, то только программеры в корпорациях за $100k в год(после этого опыта они уходят, часто больше никогда не возвращаясь в программирование).

А вот компилятор для Object Pascal(FPC) поддерживать намного легче, даже с разными версиями языка для исторической совместимости.

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

Сколько языков поддерживает clang? Новость о GNU Compiller Collection.

grem ★★★★★ ()

Отличные изменения, давно пора было!

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

Может, он имел ввиду ARMv6 или ARMv4? А может, ARM64?

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

Работает быстрее

Что? clang как раз таки быстрее компилирует исходники, чем gcc. Насчёт качества кода не скажу. Вроде как на некоторых тестах clang уделывает gcc, а на некоторых наоборот.

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

кишинев, молдова, Object Pascal. ясно.

anonymous ()

-std=gnu++14

а чем этот режим отличается от ключа "-std=c++14"?

добавлением своих дополнительных фич?

grem ★★★★★ ()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

Если зен всосёт, то не из-за отсутствия каких-то там инструкций.

anonymous ()
Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined.

https://gcc.gnu.org/gcc-6/changes.html

anTaRes ★★★★ ()
Последнее исправление: anTaRes (всего исправлений: 1)
Ответ на: комментарий от FilosofeM

FilosofeM> Чем оно лучше Clang?

Clang до сих пор не научился компилировать код на таких языках как pascal и ada, например.

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

Чем оно лучше Clang?

Clang не сможет собрать ядро Линукса.

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

clang как раз таки быстрее компилирует исходники, чем gcc

К сожалению, уже давно не быстрее, а медленнее:

$ export TIMEFORMAT=%R
$ for i in $(seq 1 3); do time make -B CXX=clang++ &> /dev/null; done 2>&1|awk '{sum+=$1} END{printf "avg: %.2f\n", sum/NR}'
avg: 5.63
$ for i in $(seq 1 3); do time make -B CXX=g++ &> /dev/null; done 2>&1|awk '{sum+=$1} END{printf "avg: %.2f\n", sum/NR}'
avg: 5.08

$ g++ --version|head -1
g++ (Debian 5.3.1-14) 5.3.1 20160409
$ clang++ --version|head -1
clang version 3.8.0 (http://llvm.org/git/clang.git 2d49f0a0ae8366964a93e3b7b26e29679bee7160) (http://llvm.org/git/llvm.git ff65de018b6bb5bc4da3e923bbc0f55c5ca8e039)

Это мелкий мини-проект, на больших проектах (например сборка самого LLVM) разница гораздо сильнее (в полтора-два раза).

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

Некоторые исходники clang скомпилировать не может by design.

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

Вроде недавно был GCC 5.0.

+1 я тоже удивился. Сам все ещё на 4 ветке сижу, почувствовал себя некрофилией.

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

ЕМНИП Интел туда много чего отдала, в дело оптимизации под свои процы.
А у них самый лучший компилер для x86.

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

Сколько языков поддерживает clang? Новость о GNU Compiller Collection.

Шланг вообще-то только один из фронтендов llvm. И не единственный

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

Блин, да GCC тупо всем лучше Clang...
лучше

Вы лукавите.

Если бы не clang, то gcc не развивался бы вообще. Конкуренция пошла на пользу.

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

Настало время вбрасывать аргументы более весомые чем собственное мнение.

А кто мешает вам запилить бенч и проверить?

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

Конкуренция

А я и не говорю, что Clang совершенно бесполезен и «ненужно». Я говорю, что современный GCC по всем значимым для компилятора характеристикам лучше современного Clang. Возможно когда-то это изменится, но пока так...

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

Да даже в толксах у кого-то недавно бомбануло о том, что GCC оказался чуток быстрее.
Тем более, когда мы говорим о бенчмарках компиляторов, то тут нужно собаку съесть и не одну, чтобы создать такой тест, который не вызовет возражений у подавляющего большинства.

Stahl ★★☆ ()
Ответ на: комментарий от anTaRes

Value range propagation now assumes that the this pointer of C++ member functions is non-null.

Проверяльщики аля «if(this == nullptr) return;» ненужны.

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

Clang до сих пор не научился компилировать код на таких языках как pascal и ada, например.

А почему C-компилятор должен это уметь?

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

Тем более, когда мы говорим о бенчмарках компиляторов, то тут нужно собаку съесть и не одну, чтобы создать такой тест, который не вызовет возражений у подавляющего большинства.

Не нужно есть никакую собаку. Нужно взять свой проект, собрать его gcc и clang, а результаты скорости сборки и скорости исполнения сравнить.

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

На нашем достаточно большом проекте, три года назад, код сгенеренный интеловским компилером работал медленнее. Самый быстрый был у gcc. Собирали и под Linux и под винду, так что вижуал студия 2008 (новее не пробовали) тоже участвовала в сравнении.

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

Без указания ключей оптимизации компилеров ниачом.

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

Блин, да GCC тупо всем лучше Clang

кроме, пожалуй, внутренней архитектуры (хотя, может, слухи и обманчивы). LLVM сделали офигенную площадку для клепания компиляторов, разбора кода и прочего. Так что оба проекта нужны и важны.

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