После года разработки состоялся (https://gcc.gnu.org/ml/gcc-announce/2016/msg00000.html) релиз свободного набора компиляторов GCC 6.1 (https://gcc.gnu.org/gcc-6/), первый значительный выпуск в новой ветке GCC 6.x. В соответствии с новой схемой (https://gcc.gnu.org/develop.html#num_scheme) нумерации выпусков, версия 6.0 использовалась в процессе разработки, а незадолго до выхода GCC 6.1 уже ответвилась ветка GCC 7.0, на базе которой будет сформирован следующий значительный релиз GCC 7.1.GCC 6.1 примечателен применением в компиляторе C++ по умолчанию стандарта C++14 вместо ранее предлагаемого C++98, улучшением экспериментальной поддержки C++17, расширением средств диагностики, полной поддержкой OpenMP 4.5, новыми оптимизациями, поддержка системной библиотеки musl, улучшением поддержки платформ ARM, поддержкой процессоров AMD Zen (17 поколение CPU AMD), Intel Skylake, IBM z13 и IBM POWER 9.
Основные изменения (https://gcc.gnu.org/gcc-6/changes.html):
- Для языка C++ по умолчанию активировано использование стандарта C++17 (применяется режим "-std=gnu++14" вместо "-std=gnu++98"). Добавлена поддержка расширения системы шаблонов C++ Concepts (https://en.wikipedia.org/wiki/Concepts_%28C%2B... активируемая опцией "-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 (https://www.opennet.ru/opennews/art.shtml?num=39365), которую можно использовать на Linux-системах с архитектурой AArch64, ARM, MicroBlaze, MIPS, MIPS64, PowerPC, PowerPC64, SH, i386, x32 и x86_64. Поддержка включается опцией "-mmusl";
- Многочисленные улучшения оптимизатора: Добавлены новые внутрипроцедурные оптимизации и оптимизаций во время динамического связывания, улучшена работа детектора неопределенного поведения (Undefined Behavior Sanitizer);
- Значительно расширена поддержка спецификации OpenACC 2.0a (http://www.openacc.org/), определяющей средства для выноса (https://gcc.gnu.org/wiki/Offloading) операций на плечи GPU.
Добавлена начальная поддержка параллельного выполнения ядер OpenACC. Для выноса вычислений могут быть задействованы GNU NVIDIA PTX на Linux-системах с процессорами x86_64 и PowerPC. Поддерживается распараллеливание с запуском до 32 обработчиков и 32 векторов.- В компиляторах C и C++ полностью реализована спецификация OpenMP 4.0 (Open Multi-Processing), позволяющая ускорить вычисления за счёт выноса операций (offloading (https://gcc.gnu.org/wiki/Offloading)) на специализированные процессоры Intel XeonPhi Knights Landing и AMD HSAIL.
- Начальная поддержка гетерогенных вычислительных систем на базе архитектуры HSA (https://www.opennet.ru/opennews/art.shtml?num=42087). Реализована возможность генерации промежуточного языка HSAIL (Heterogeneous System Architecture Intermediate Language) для простых устройств OpenMP при сборке с опцией "--enable-offload-targets=hsa". Добавлен плагин libgomp, позволяющий запустить ядра HSA GPU на GPU, совместимых с HSA.- Расширены средства сборки генератора кода в форме разделяемой библиотеки libgccjit для встраивания в другие процессы и использования для организации JIT-компиляции байткода в машинный код;
- Объявлена устаревшей поддержка старых архитектур ARM, предшествующих ARMv4t: arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7d, arm7di, arm70, arm700, arm700i, arm710, arm720, arm710c, arm7100, arm7500, arm7500fe, arm7m, arm7dm, arm7dmi, arm8, arm810, strongarm, strongarm110, strongarm1100, strongarm1110, fa526, fa626. В будущем поддержка данных систем будет прекращена.
- Добавлена поддержка новых процессоров ARM: ARM Cortex-A32 (cortex-a32), ARM Cortex-A35 (cortex-a35);
- Улучшения для процессоров IA-32/x86-64: Добавлена поддержка процессоров AMD Zen (-march=znver1 и -mtune=znver1) и Intel Skylake с расширениями AVX-512 (-march=skylake-avx512) AVX-512F, AVX512VL, AVX-512CD, AVX-512BW и AVX-512DQ. Добавлена поддержка инструкций monitorx и mwaitx, используемых в CPU AMD. Добавлена поддержка адресных пространств __seg_fs, __seg_gs и __seg_tls;
- Начальная поддержка процессоров POWER9, использующих набор инструкций OpenPOWER ISA 3.0. Для систем PowerPC64 обеспечена поддержка 128-разрядных чисел с плавающей запятой (IEEE 128-bit floating-point) с использованием типа __float128 ("-mfloat128");
- Добавлена поддержка процессоров IBM z13 (-march=z13), используемых в новых платформах IBM z Systems;
- Расширены возможности порта AArch64 и добавлены специфичные для данной архитектуры опции. На системах GNU/Linux AArch64 реализована поддержка опций "-march=native" и "-mcpu=native", при которых GCC сам определяет тип CPU и выбирает набор оптимальных настроек. Реализована поддержка опций "-mtls-size=" и "-fno-plt". Добавлена поддержка архитектуры ARMv8.1-A ("-march=armv8.1-a"), процессора ARM Cortex-A35 ("-mcpu=cortex-a35", "-mtune=cortex-a35") и расширений для крупных систем (Large System Extensions). Улучшена генерация кода для процессоров ARM Cortex-A53 и Samsung Exynos M1.
- В разряд устаревших переведены (https://gcc.gnu.org/ml/gcc/2015-08/msg00101.html) платформы SH5 / SH64 (sh64-*-*) и MeP (mep-elf).URL: https://gcc.gnu.org/ml/gcc-announce/2016/msg00000.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=44326
Инкремент мажорной версии каждый год. гугле стиль, еп
Не позорь имя анона. Мажорная версия должна быть сменена в данном случае, поскольку изменили стандарт по умолчанию и выкинули поддержку кучи процессоров и архитектур. Т.е. поломали обратную совместимость (не все что компилилось пятеркой, компилится 6), поэтому изменение мажорной цифры правильно.
>выкинули поддержку кучи процессоров и архитектурПометили устаревшей, но ещё не выкинули.
ты сам не позорься. Новость прочитай хотя бы "В соответствии с новой схемой нумерации выпусков"
> ты сам не позорься. Новость прочитай хотя бы "В соответствии с новой схемой нумерации выпусков"+1, в списках рассылки это было описано ещё перед выходом 5.1. Они теперь КАЖДЫЙ релиз будут увеличивать мажорную версию. Можно, конечно, предположить, что они каждый раз будут ломать обратную совместимость, но это маловероятно.
Причём дурнее схемы я ещё не видел. Первый релиз ветки X носит номер X.1, а не X.0. В каждом релизе есть три цифры, но последняя всегда ноль (но всё равно не отбрасывают её). То есть для каждой ветки X номера версий будут X.1.0, X.2.0, X.3.0, X.4.5...
и почему это вы не могли им посоветовать во времена перехода с 2.7 до 2.9?
Ага, google свой хром уже 50 лет разрабатывает.
Скорее GNU GCC 6 лет разрабатывают
А less разрабатывается уже 481 год.
Какие цели преследует этот выпуск? Новые фичи это следствие бурной деятельности программиздов, или же они были добавлены для решения конкретных проблем возникающих при написании кода?
> Какие цели преследует этот выпуск?Ты читать что ли не умеешь.
"Лёгким движением руки брюки превращаются... Брюки превращаются... Превращаются брюки... В элегантные шорты!"(С)
Скоро СиПлюсПлюшечка превратиться в уютненький СиШарпик, и заметьте я не говорю, что это плохо.
Да, и чтобы теперь стать знатоком СиПлюсиков понадобиться пять-шесть десятков лет, но комитетчики не унывают и пихают новые фичи как не в себя.
Молодцы, чо! Скоро они СиПлюшечку похоронят под грудой этих улучшений. И самое забавное в том. что десятилетиями они не чесались, а тут решили пятилетку за три года перевыполнить.
Хорошая была СиПлюшечка, но видать судьба у неё такая - незадачливая. Товарищ Страуструпов переворачивается с боку на бок от бессонницы и тяжко вздыхает.
Альтернативы все равно нет, разве что раст выстрелит, но это еще когда будет...
Товарищ Страуструпов половину этих новинок активно пропихивал лично. Кому надо "простое" - шуруйте в джаву, пишите простыни и учите горы либ. А здесь - плюсы очень добротно осовременили.
Т.е. в плюсах кучу либ учить не нужно? http://s.pikabu.ru/post_img/2012-12_5/1356251055_1061087425....А Страуструп вообще странный человек. Может быть он хороший программист, но учитель и объяснятор ппц ни какой ... Недавно (в 2016) вышло второе издание "Программирование. Принципы и практика с использованием C++", так он там с первых страниц не разжёвывает с самых низов, а сразу говорит, чтобы примеры линковали с его хедером самописным (где его самопальные обёртки), а потом (в самом начале) без объяснения шаблонов, структур и классов начинает на ровне с int, char приводить примеры string, vector. Новичок вообще до сумасшествия запутается в таком подходе обучения ...
Нет, не нужно. Я уже тут сто раз объяснял - сложность задачи - она никуда не девается. Она раскладывается на язык, библиотеки и собственно софт, который пишешь. Вот для джавы простота языка вынуждает сложность упихивать в монструозные либы с кучей классов и писать портянки с set/get вместо []. На плюсах, особенно новых, без этого обычно можно обойтись - но то, что пишешь, будет использовать более сложные конструкции, это да.Разница - примерно как между иероглифическим письмом (ладно - слоговым) и алфавитным. В одном случае кучу всего запоминать, в другом - сложнее правила формирования текста. А если сказать надо одно и то же - то усилия, по факту, сравнимы - только прикладываются на разный манер. Вот мне вариант плюсов куда ближе - раз понял концепцию, и используй где угодно. Даже если для понимания нужны некие усилия.
А картинка дурацкая. Ни одну индустриальную технологию за 21 день не выучишь - и не в синтаксисе дело.
Новое издание книги Страуструпа я не смотрел, так что насчёт всего не отвечу, но насчёт string и vector - правильно делает, IMHO. Сейчас для плюсов - это фактически встроенные типы, так их и надо воспринимать. То, что они находятся в библиотеке и можно их реализацию глянуть - приятный бонус, не более. А писал он в своё время очень живо, "The Design and Evolution of C++" читалась на ура - и, кстати, must read для любого плюсовика - там объясняется ПОЧЕМУ в плюсах сделано так, а не иначе, а это дорогого стоит.
>> Ни одну индустриальную технологию за 21 день не выучишья вас умоляю, посмотрите на GO.
смотри на Swift
>Недавно (в 2016) вышло второе издание "Программирование. Принципы и практика с использованием C++", так он там с первых страниц не разжёвывает с самых низовЭта книга никогда не рассматривалась как учебник для начинающих. А вообще да, у него книга как язык C++ (не зря именно он его придумал): немного там, немного там, сложишь вместе и получились знания.
Эта книга именно для начинающих и не знакомых с программированием вообще. У него несколько книг, но ты же ленивый чтобы самостоятельно это узнать. Решил сразу с дивана прокукарекать.
Книгу читал. В отличие от тебя, знаю что пишу.
> Молодцы, чо! Скоро они СиПлюшечку похоронят под грудой этих улучшений.Сама идея С++ была порочна. Это всё равно что создавать новое произведение искусства путём приделывания рук Венере Милосской или пририсовывания бровей Джоконде. А раз уж пририсовал брови, то почему нельзя пририсовать ещё и туловище, руки, ноги и хвост...
>Сама идея С++ была порочна.Ты прав бро, только ничего лучше пока не придумали
Придумали. Для системного/встроенного программирования - Си. Для прикладного - всё что угодно, начиная с Делфи и кончая этим вашим Питоном.
Си уже неприменимо ни для чего, это устаревшее неэффективное небезопасное г-но, NTP с сотнями критических уязвимостей - отличный пример того что на нём единственно можно написать. Даже эмбеддовку уже давно тоже пишут на плюсах, а для прикладухи других языков никогда и не существовало.
Ха-ха, это даже не смешно. Вы поинтересуйтесь на досуге, на чём написаны ядра операционных систем промышленного уровня.
Мы здесь не говорим о промышленных системах. Только о самодельном локалхостном гогне, пофигу где оно стоит.
https://www.youtube.com/watch?v=Xf6rL0IUjmM
> Молодцы, чо! Скоро они СиПлюшечку похоронят под грудой этих улучшений. И самое
> забавное в том. что десятилетиями они не чесались, а тут решили
> пятилетку за три года перевыполнить.C++ вообще-то никуда особенно не превращается. Эти их последние ...14, 17... и т. п. - это и вовсе не C++. Это можно сказать грубый черновик чернового собрания разных далеко идущих модификаций и добавлений. И да, название ему пожалуй - СиПлюшечка разве что.
Поэтому на текущий момент нормального развития C++ на самом деле не имеем. Как и стандарта. Хотя и есть обширные черновые наброски собрания черновиков разных возможностей добавлений.И кто является главным потребителем всех этих "плюплюплюшечек"? Разве что всякие Хромиумы...
У KDE и вовсе свой тоже далеко зашедший язык (с QStringами и прочим...)...
> версия 6.0 использовалась в процессе разработкиМне как-то 5.99 более понятно. А с релизом 6.1 всегда вопрос: как же я 6.0 пропустил!?
>> версия 6.0 использовалась в процессе разработки
> Мне как-то 5.99 более понятно. А с релизом 6.1 всегда вопрос: как
> же я 6.0 пропустил!?Новая нумерация же: Вы не понимаешь, я не понимаю -- ну и хххн с ним, с плащом.
https://www.opennet.ru/openforum/vsluhforumID3/102196.html#21Или Вы полагаете, что именно Ваше Мнение "всё изменит"тм? Не стОит.
И никто ничего не пропустит: обсуждение "новой" нумерации теперь будет под каждой новостью -- *всегда*. Это удобно, Вы привыкнете.
6.1 для gtk-шников - это вообще test-ветка. Просто одно дело формально утвердить, что будет такая нумерация, а другое дело, как она подсознательно воспринимается. Из-за ядра 2.5 и gtk, нечетный номер уже глубоко засел как тест. Ну, а начинать с .1 релиз - это...
Какая разница как оно подсознательно воспринимается? У нас что - психоанализ? Вам разработчики объявили, что это релиз. На опеннете еще и на русский перевели. Но на опеннете самые несчастные комментаторы, если у них какие-то несчастные цифры вызывают истерики.
> Добавлена поддержка транзакционной памятиОна же всё ещё ни в одном интеловском проце не работает, т.к. обнаружились железные баги, и её отключили?
Уже давно работает. В Broadwell и Skylake. Возможно, и в Haswell некоторых моделей.Только то, что написано в release notes - совершенно о другом.
> Уже давно работает. В Broadwell и Skylake. Возможно, и в Haswell некоторых
> моделей.Да, ладно. Август 2014 TSX отключён в Haswell из-за бага. Февраль 2016 и в Haswell тоже.
> Только то, что написано в release notes - совершенно о другом.
Т.е. софт-эмуляция?
Похоже, TSX не выключен только в каких-то избранных моделях и является исключением, а не правилом.
>Да, ладно. Август 2014 TSX отключён в Haswell из-за бага. Февраль 2016 и в Haswell тоже.В Xeon E7 v3 оно есть и включено.
Но это не очень народный проц. А TSX уже не настолько нов, чтобы по-прежнему быть доступным только избранным.
> Но это не очень народный проц. А TSX уже не настолько нов,
> чтобы по-прежнему быть доступным только избранным.Зато он _дорого_ штеуду. Штеуд всегда и постоянно барыжит "пупер"-фичами в настольных-ненастольных камнях, уж не говоря об доступный-недоступный.
У них и "тупая" аппаратная виртуализация для престарелого kvm-а долго-долго была не в каждом настольном или ноутбучном камне. В планшетно-телефонных калькуляторных цпу-аналогах, уверен, и сейчас её нет, ну, да, там и не надь, это я понимаю. Но в настольных... "Просто бизнес" же. Я привыкнул, все привыкли -- вы сделали это Открытие и тоже привыкнете, ничего-ничего.
> Февраль 2016 и в Haswell тоже.Опечатался: в Skylake.
Пруф?
https://www.reddit.com/r/hardware/comments/44k218/intel_disa.../Кроме TSX, ещё и HLE в куче процессоров сломан: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574
> https://www.reddit.com/r/hardware/comments/44k218/intel_disa.../Чувак сидит на i3, в котором TSX и не должен быть.
> Кроме TSX, ещё и HLE в куче процессоров сломан: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574
HLE - часть TSX. Судя по обсуждению, исправлено микрокодом. Трудности с обновлением микрокода в Debian к делу не относятся.
> Чувак сидит на i3, в котором TSX и не должен быть.Точно? Он же доказательство привёл: http://web.archive.org/web/20151119222457/http://ark.intel.c... что поддерживалось (Intel® TSX-NI Yes), а потом вдруг решили, что нет (Intel® TSX-NI No).
> HLE - часть TSX. Судя по обсуждению, исправлено микрокодом.
Если исправлено, то замечательно, а вот если обошли ценой потери производительности, то значит не совсем юзабельно. Вот какое из этих двух?
> Точно? Он же доказательство привёл: http://web.archive.org/web/20151119222457/http://ark.intel.c... что поддерживалось (Intel® TSX-NI Yes), а потом вдруг решили, что нет (Intel® TSX-NI No).Ошибки на ark.intel.com появлялись и раньше, это далеко не первый раз. Да, если ты ориентируешься на этот сайт при покупке проца, то можешь попасть. Так же, как и ориентируясь на любой другой источник информации. Tough luck.
>> Только то, что написано в release notes - совершенно о другом.
> Т.е. софт-эмуляция?Я так понимаю, это об этом:
https://isocpp.org/files/papers/N3919.pdf
В реализации может использоваться аппаратная поддержка, если она есть. Если нет, то в софте.
Как это Вы не слышали? Fedora уже пакеты перевела на GCC 6
> Для языка C++ по умолчанию активировано использование стандарта C++14 (применяется режим "-std=gnu++14" вместо "-std=gnu++98").Опять будет куча не совместимых с стандартом вещей - зато от GNU ?
> Опять будет куча не совместимых с стандартом вещей - зато от GNU ?Шланг их быстренько запилит, потому что удобно. А остальные... они где? MSVS который C99 до сих пор не умеет? Ну конечно, им только C++17 с такой прытью и реализовывать. Только кому он будет нужен в 2050?!
> MSVS который C99 до сих пор не умеет? Ну конечно, им только C++17 с такой прытью и реализовывать.Справедливости ради стоит отметить, что с поддержкой актуальных плюсовых стандартов там значительно лучше, чем с plain C.
Что за уродская привычка инкрементировать мажорные версии? Где времена ядра 2.6.х?
musl годно, хотя им куча софта не собирается, потому что слишком сильно стандарта придерживаются.
LTO тоже хорошо, пусть теперь Graphite улучшают.
Как бы в релизах ядра не начали первую цифру версии накручивать. Идея Хромого-Файерфокса заразительна.
не ссы, от тебя все равно ничего не зависит
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67984 - там даже мой багрепорт учтён и пофикшен. Всем графита.-)