GCC 7.1

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

с чего ты решил что я разрабатываю ядро линукс?

Я не о ядре Linux, им занимаются его разработчики. Я о твоём коде. Иначе почему тебя волнуют вопросы компилятора, если ты не разработчик?

о каком моем коде? ядро не компилится

Почему тебя это волнует?

а тебе то какое дело?

Потому что код ведра - хорошая тестовая база для проверки работы компилятора.

Всегда ваш.

А если код ведра устарел и требует приведения к более строгому виду?

Сначала ты ругаешь новый компилятор, потому что он не собирает ядро. На вопрос «так ты выясни — это баг или фича» — ты говоришь, что не разработчик ядра.

Стало быть, твои ругательства преждевременны без разбора ситуации, ведь, как я уже говорил, это могут быть как баги компилятора, так и более строгие проверки кода. В первом случае нужно фиксить баги компилятора, во втором — код ядра.

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

В общем, не будь истеричкой и сначала разберись в ситуации. Ты ведь не школьник, а вроде как разрабатывал Catalyst, но ведешь себя как школьник.

В нормальном компиляторе это физически не возможно:

anon@nimous:~# cat test.c
int foo(a)
   int a;
{
        return 0;
}

int main()
{
        foo();
        return 0;
}
anon@nimous:~# gcc test.c
anon@nimous:~# ./a.out
anon@nimous:~# gcc --version
gcc (Debian 6.3.0-14) 6.3.0 20170415
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Да, язык C уровня K&R именно так и работал.

Почему? Это же классика K&R http://www.iu.hio.no/~mark/CTutorial/CTutorial.html#Value parameters

ну и ядро не на чистом Си написано.

Когда-то писали -

The old versions of the assigned operators («=+», etc.) must not
be used. Always surround assigned operators by spaces. «x=*foo»
is interpreted as «x#=#x#*#foo» (even if foo is a pointer) by
some compilers.

(«A C Style Sheet», Martin Minow, Digital Equipment Corp.)

Уже 30 лет, как рекомендуется писать не

int foo(a)
int a;

а

int foo(int a)

А в генту до сих пор 5-ая ветка. Ох и слоупоки :)

да и то 5 стабильной сделали недавно...

А если код ведра устарел

Почему? Это же классика

Уже 30 лет, как рекомендуется писать не

В книге Кернигана и Ритчи по С об этом рассказывают.

Регрессии вычистите — обновим, а пока unstable.

Не рекомендуют != запрещено. А пока разрешено (не выкинули поддержку) — код валидный.

Не шлангуй. Этот код устарел 30 лет назад, но всё еще рабочий. Ведру меньше 26 лет. В ведре не может быть «устаревшего» кода.

Что грандиозного они поменяли бы в разработке?

Время компиляции программ с монструозными библиотеками типа Qt.

Что ты пытаешься доказать?

Что грандиозного они поменяли бы в разработке?

Не то ли, случаем, что можно было б при подключении #include, как сейчас, «разворачивать» его не полностью, а только то, что действительно необходимо из него в данный момент? Не должно ли это хотя бы ускорить линковку и сборку?

Поддерживаются все возможности текущего черновика будущего стандарта C++17

черновика

Надеюсь, что только в качестве расширения "-std=gnu", а не в виде "-std=c++17". Мало ли что в черновике ещё изменят, даже если незначительно.

The C++ front end has experimental support for all of the current C++17 draft with the -std=c++1z or -std=gnu++1z flags, including if constexpr, class template argument deduction, auto template parameters, and structured bindings.

Сейчас 17 стандарт как бэ принят формально, но всё ещё черновик.

принят формально, но всё ещё черновик

/0. Не принят, а «заморожен», как в debian stable.

С увеличением мажора меняется ABI. На опеннете была новость об этом.

oh shit ... specially about c++ abi ...

Теперь поддерживается ОС Fuchsia OS.

прочёл фунчоза ОС

https://gcc.gnu.org/gcc-7/changes.html#go

Ї:

Go

• GCC 7 provides a complete implementation of the Go 1.8.1 user packages.
• Compared to the Go 1.8.1 toolchain, the garbage collector is more conservative and less concurrent.
• Escape analysis is available for experimental use via the -fgo-optimize-allocs option. The -fgo-debug-escape prints information useful for debugging escape analysis choices.

Кто-то пользуется? О чем они вообще?

Добавлена поддержка архитектуры RISC-V

В каком смысле добавлена?

Риск-В вроде как сразу шёл в комплекте с GCC, или не?

Теперь поддерживается ОС Fuchsia OS.

Штоэта?

В целом новость одобряю, ГЦЦ наше все!

нунифигасе, я еще к пятому не привык... они теперь как гуглохром версии штампуют?

Оно уже может использовать кирилические переменные и прочее как шланг, или всё ещё патчить нужно?

Что с Фортраном?

Много улучшений.

Когда строки произвольной длины реализуют нормально встроенным способом?

Только не это, шеф!

Всякий желающий получить возможность писать идентификаторы кириллицей должен приготовиться читать на деванагари, иврите и китайском :)

новость о том, что gcc7 не собирает ведро была на ЛОРе.

там было описание, что конкретно сломалось.

сломалось очень плохо: по сути у тебя есть inline функция, которая не имеет side-effectов и её вызывают с константой на входе.

что раньше происходило? вызов функции унижался до её результата.

что происходит сейчас? функция написалась кодом и вызывается.

а такая функциональность - это основа компилятора. уметь заменять 2*2 на 4. и она сломана.

Проблема в оптимизации GCC 7: Ядро наступает на грабли разрабатываемого GCC 7 .

Ядро 4.11 при помощи GCC 7 собрать вполне можно.

что раньше происходило? вызов функции унижался до её результата

Весь ваш ГНУ - одно унижение и доминирование! Как хорошо что это убрали.

В смысле нормально? Встроенныс это как? Длину строки в коде? Она ограничена стандартом в 132 символа для свободной формы, 72 для фиксированной. Можно снять ограничение ключом компилятора. Или длина строки типа character(:)? А с ней что не так?

что значит «проблема в оптимизации»?

2+2=5 это что, «проблема в вычислениях»? это не проблема, это значит что всё сломано.

Смотри: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

Сам Линус починил ядро, а не показал палец GCC7. Яркий пример.

И вообще, для таких случаев придумали static_assert, но ребята хотят оставаться в веке динозавров. Вот пусть и пишут свои костыли.

у нас есть функция без циклов и side-effectов. её вызывают с константой на входе. есть такая штука: constant folding. если написано 2+2, то можно сразу сократить это до 4, например. раньше gcc это делал. теперь что-то сломалось.

как ты думаешь, оно только на ведре сломалось, или где-то ещё сломано?

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

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

GCC включился в гонку версий? Вроде еще несколько лет назад пользовался 4.8.*, а тут как то три мажорные версии проскочили.

Судя по Mingw из состава Qt, они тоже не особо успевают за GCC.

Эх, а в C++ есть conts_expr. А тут пытаются прикрутить колёса к буханке хлеба.

ну есть. ну да, есть.

только оптимизатор в данном конкретном случае должен был константное выражение свернуть. это настолько базовая функциональность, что дальше уж некуда. он же умел раньше.

вот в чем проблема. ведро первым наступило на эту мину.

5.3 в целом хватает для большинства задач. В msys2 GCC6 и тот же Qt есть.