После года разработки состоялся (https://gcc.gnu.org/ml/gcc-announce/2017/msg00000.html) релиз свободного набора компиляторов GCC 7.1 (https://gcc.gnu.org/gcc-7), первый значительный выпуск в новой ветке GCC 7.x. Релиз приурочен к 30-летию с момента формирования первого выпуска GCC 1.0. В соответствии с новой схемой (https://gcc.gnu.org/develop.html#num_scheme) нумерации выпусков, версия 7.0 использовалась в процессе разработки, а незадолго до выхода GCC 7.1 уже ответвилась ветка GCC 8.0, на базе которой будет сформирован следующий значительный релиз GCC 8.1.GCC 7.1 примечателен удалением из состава компилятора для языка Java, реализацией экспериментальной поддержки грядущего стандарта
C++17, расширением средств диагностики, реализацией новых оптимизаций, поддержкой OpenMP 4.5 для GPGPU NVidia PTX.
Основные изменения (https://gcc.gnu.org/gcc-7/changes.html):- Во фронтэнде для языка С++ реализована экспериментальная поддержка всех возможностей черновика стандарта C++17. Для включения следует использовать опции "-std=c++1z" и "-std=gnu++1z". В библиотеку libstdc++ также добавлены почти все возможности, представленные в C++17;
- Существенно расширены средства диагностики ошибок, добавлены новые предупреждения, улучшено отслеживание местоположения переменных и вхождение в диапазон допустимых значений. Существенно расширена система рекомендации по устранению проблем (например, предупредит о "%s" в printf, если значение "i + j") и предложений по замене опечаток в идентификаторах (gtk_widget_showall => gtk_widget_show_all), типах (singed => signed), макросах (array[MAX_ITEM] => array[MAX_ITEMS]) и директивах препроцессора endfi => endif);
- Многочисленные улучшения оптимизаций: добавлены новые оптимизации во время динамического связывания, межпроцедурные и внутрепроцедурные оптимизации. Реализованы дополнительные методы слияния стадий компиляции, выноса операций за пределы циклов, разбиения циклов на части;
- В Address Sanitizer добавлен отчёт об использовании переменных;
- Добавлена возможность использования OpenMP 4.5 для ускорения вычислений за счёт выноса операций (offloading) на специализированные процессоры NVIDIA PTX;
- Из состава GCC удалены все компоненты компилятора GCJ (https://gcc.gnu.org/java/) (GNU Compiler For Java). Инициатива по удалению GCJ стартовала ещё в 2013 году и связана с запущенным состоянием GCJ, который много лет не развивается (полностью поддерживается (https://gcc.gnu.org/onlinedocs/gcj/Limitations.html#Limitations) только Java 1.2) и содержит ряд проблем, мешающих применению GCJ на практике. Кроме того, смысл существования GCJ стал неоправдан после сосредоточения разработки открытых компонентов Java в проекте OpenJDK, который также распространяется под лицензией GPL;
- Для новых целевых платформ задействован (https://gcc.gnu.org/wiki/LRAIsDefault) по умолчанию новый механизм распределения (https://gcc.gnu.org/wiki/RegisterAllocation) регистров LRA (Local Register Allocator), реализующий метод рематериализации, при котором вместо сохранения значения регистра при необходимости используется его повторное вычисление;
- Режим профилирования libstdc++ (https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode...) объявлен устаревшим и будет удалён в будущих выпусках;
- Объявлен устаревшим Cilk+ (https://www.opennet.ru/opennews/art.shtml?num=31517), набор расширений для языков Си и Си++ с реализацией предложенной компанией Intel методики параллельного программирования;
- Добавлена поддержка формата отладочной информации DWARF 5 (опция -gdwarf-5). По умолчанию по-прежнему используется DWARF 4;- Добавлена поддержка обработки файлов в бинарном формате BRIG 1.0, предназначенном для использования с языком HSAIL (Heterogeneous System Architecture Intermediate Language). В состав включена runtime-библиотека libhsail-rt для HSAIL. GCC-фронтэнд для BRIG может использоваться для реализации финализаторов HSAIL (вариант HSAIL, скомпилированный для заданных процессоров);
- Добавлена поддержка AArch64-архитектур ARMv8.2-A и ARMv8.3-A (-march=armv8.3-a), а также процессоров ARM Cortex-A73 (cortex-a73), Broadcom Vulcan (vulcan), Cavium ThunderX CN81xx (thunderxt81), Cavium ThunderX CN83xx (thunderxt83), Cavium ThunderX CN88xx (thunderxt88), Cavium ThunderX CN88xx (thunderxt88p1), Cavium ThunderX 2 CN99xx (thunderx2t99) и Qualcomm Falkor (falkor).
URL: https://gcc.gnu.org/ml/gcc-announce/2017/msg00000.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=46487
Кто уже пробовал собрать новым GCC 7.1 систему FreeBSD 11-STABLE из сорцов?
ну или вы или netflix. вы, судя по всему, не пробовали, netflix вам здесь не ответит.
> Объявлен устаревшим Cilk+Да ладно! Её Intel так пиарил...
энтерпрайз он такой - политика партии поменялась и оказалось, что имярек никому не нужен. потому и нельзя опенсорсу завязываться на энтерпрайз технологии.
Хотя во многих случаях кговавый ынтерпрайз делает этот ваш опен соурс.
> gtk_widget_showall => gtk_widget_show_all), типах (singed => signed)Кто-нибудь уже смотрел? Оно как-то локально хто хранит, или к стороннему серверу обращается? Можно ли это как-то отключить?
Наверняка просто парсит #include файлы + список ключевых слов + функции стандартной библиотеки типа printf, сторонний сервер тут совсем не нужен
Имел ввиду, как он определяет "степень похожести", что один идентификатор похож на один из правильных, а другой - нет?
Видимо тупо подбирает идентификатор из объявленных с минимальным расстоянием левенштайна между ним и отсутствующим.
Так же, как и spellchecker.
Есть такое понятие: расстояние Хэмминга: https://ru.wikipedia.org/wiki/%D0%A0%D0%...
Фича с подсказками по опечаткам лет 10-15 есть в aCC у Intel/HP.
> Кто-нибудь уже смотрел? Оно как-то локально хто хранит, или к стороннему серверу обращается?Оно смотрит в хэдеры и в описания структур, функций и пр..
> Можно ли это как-то отключить?
Зачем? (но можно не включать, например, -Wimplicit-function-declaration)
>Поддержка развиваемого компанией Google языка программирования Go обновлена до версии 1.8.1;
>GCC - GNU C CompilerНикогда не понимал зачем они пихают в свой компилятор поддержу Java/Go/etc, которые к тому же имеют свои "родные" вполне хорошие компиляторы. Почему просто не делать хороший C/C++ компилятор?
Потому что "родные" компиляторы Java/Go требуют для сборки уже имеющийся бинарный Java/Go. Который, в свою очередь, можно получить лишь скомпилировав исходники Java/Go другим уже имеющимся бинарным компилятором Java/Go. Который... и т.д.И после установки бинарного Java/Go, необхдоимого для сборки Java/Go из исходников, у любого нормального человека возникает вопрос, а зачем вообще собирать Java/Go из исходников, если у меня УЖЕ есть рабочий Java/Go?
Надеюсь, мысль ясна.
Насколько я помню gcc go круче оптимизирует чем оригинальный компилятор.
Когда как.
У проекта GNU свое определение хорошести - свободность. В частности, когда создавался GCJ, сановская Java была проприентарной, что, собственно, и послужило причиной. Что там с Go не в курсе, но, вроде бы, gccgo - практически эталонная реализация.
Эм. Как бы не то что родного, а более-менее вменяемого актуального компилятора java в нативный код нет. Все пытались, включая Гугль, но рано или поздно бросали это дело. неблагодарное это дело. Так что как была интерпретатором (jit-компилятором) так и остается.
> Как бы не то что родного, а более-менее вменяемого актуального компилятора
> java в нативный код нет.Кто ж тебе его напишет? Изень? Или лютo-жабo-быдлo-кoдер?
Дмитрий Чуйко "Ahead-of-Time компиляция для HotSpot JVM": https://www.youtube.com/watch?v=hRepfVJZvhYС 33 минуты примерно.
Что за поддержка языка Go в GCC? Не понял, что теперь во всех дистрибутивах с GCC будет из коропки Golang?
Скорей всего идет отдельным пакетом. GCJ/fortran/ObjC всегда отдельными пакетами паковали в дистрах.
Даже в Slackware он отдельным пакетом идет.
Гaвнистый релиз. Мой код перестал линковаться с LTO. Хедеры libstdc++ перестали компилироваться с Clang 4.0. В GCC 6.3.0 всё работало. Прийдется ждать первого сервис пака^H^H^H 7.2.
Когда же появится поддержка UTF-имён перемененных как в шланге ?
Вы, батенька, по 1С хотите поностальгировать?