LINUX.ORG.RU
ФорумTalks

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

 , ,


2

5

Сабж. Релиза GCC 7, конечно, ещё не было, но планируемое время релиза (середина апреля) стремительно приближается, а баги всплывают и всплывают. Теперь на грабли GCC 7 наступает ядро, о чём можно прочитать в Changelog'е 6-го патча к ядру 4.10, который вышел на днях:

commit afd4fdd0da4921a9086b9ea7f9e9214caa990bb3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Mar 2 12:17:22 2017 -0800

    give up on gcc ilog2() constant optimizations

    commit 474c90156c8dcc2fa815e6716cc9394d7930cb9c upstream.

    gcc-7 has an "optimization" pass that completely screws up, and
    generates the code expansion for the (impossible) case of calling
    ilog2() with a zero constant, even when the code gcc compiles does not
    actually have a zero constant.

    And we try to generate a compile-time error for anybody doing ilog2() on
    a constant where that doesn't make sense (be it zero or negative).  So
    now gcc7 will fail the build due to our sanity checking, because it
    created that constant-zero case that didn't actually exist in the source
    code.

    There's a whole long discussion on the kernel mailing about how to work
    around this gcc bug.  The gcc people themselevs have discussed their
    "feature" in

       https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

    but it's all water under the bridge, because while it looked at one
    point like it would be solved by the time gcc7 was released, that was
    not to be.

    So now we have to deal with this compiler braindamage.

    And the only simple approach seems to be to just delete the code that
    tries to warn about bad uses of ilog2().

    So now "ilog2()" will just return 0 not just for the value 1, but for
    any non-positive value too.

    It's not like I can recall anybody having ever actually tried to use
    this function on any invalid value, but maybe the sanity check just
    meant that such code never made it out in public.

★★★★★

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

А мне зачем? У меня в продакшене только бинарные дистрибутивы, я не извращенец, чтоб гентоо и рач на боевые серваки пихать.

svr4 ()
Ответ на: комментарий от moot

а причем здесь КОИ8?

При том что для отображения ругательств от Торвальдса она не нужна. 🖕

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

Переделали бы [...]

Начинай.

А мне зачем?

А им зачем?

я не извращенец

Прокурору.

tailgunner ★★★★★ ()

Оно так не первый раз помоему.

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

Начинай.

Это так не работает. Бессмысленно строчить патчи, если их просто не примут. И дело не только в качестве самих патчей.

i-rinat ★★★★★ ()
Ответ на: комментарий от tailgunner

Но прикольно было бы посмотреть, как этот герой начнет избавляться от gсс-змов.

А почему этот герой должен начать избавляться от gcc-измов? Он только выдвинул предложение сделать это. Себя, в качестве исполнителя, он не предлагал.

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

Но прикольно было бы посмотреть, как этот герой начнет избавляться от gсс-змов.

А почему этот герой должен начать избавляться от gcc-измов?

Не вижу, где я написал, что он что-то должен.

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

Не вижу, где я написал, что он что-то должен.

Я неправильно понял фразу «начинай»?

Очевидно, да.

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

а потом придет яббл и зароет этот шланг.

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

тут проблема ширше, ширее.

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

т.е. теперь gcc7 как минное поле. хз где бомбанет

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

т.е. теперь gcc7 как минное поле. хз где бомбанет

Как будто это впервые с gcc случилось.

hateyoufeel ★★★★★ ()

Почему нельзя писать по стандарту языка Си и не привязываться к конкретному компилятору?

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

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

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

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

Ну вот например на конкретную реализацию memcpy() тоже завязывались, и от этого были плюшки...

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

Почему нельзя писать по стандарту языка Си и не привязываться к конкретному компилятору?

Потому что в стандарте C нет многих вещей, которые требуются при разработке ядра. Различные __attribute__, inline asm и прочие штуки.

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

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

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

Это было бы справедливо по отношению к прикладному софту. Но ядро имеет совсем иной уровень работы с железом и оптимизации.

bbk123 ★★★★★ ()
Ответ на: комментарий от cvs-255

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

Ну, если бы linux был микроядром, таких проблем почти не было бы, т.к. объём кода, где эти фичи необходимы, был бы сильно ограничен.

hateyoufeel ★★★★★ ()

Что-то надуманная у них проблема. Обязательно ли там нужна ошибка компиляции? Можно например на ноль поделить, варнинг будет

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

Я неправильно понял фразу «начинай»?

Он примерно настолько должен «начинать», насколько они должны «Переделали бы».

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

GCC 7 - это слишком новые версии для тебя

секунду. до меня только сейчас дошло. а что, GCC 5 уже из беты вышел? у меня 4.9.4 стоит

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

секунду. до меня только сейчас дошло. а что, GCC 5 уже из беты вышел? у меня 4.9.4 стоит

динозавры такие динозавры...

[ ~ ]$ gcc -v
Используются внутренние спецификации.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-linux/6.3.0/lto-wrapper
Целевая архитектура: x86_64-linux
Параметры конфигурации: ../gcc-6.3.0/configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --with-system-zlib --enable-install-libiberty --build=x86_64-linux --disable-bootstrap
Модель многопоточности: posix
gcc версия 6.3.0 (GCC) 
[ ~ ]$ uname -a
Linux 4.9.5 #1 SMP Tue Feb 28 14:47:32 +05 2017 x86_64 GNU/Linux

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

особо не вникал, субъективно «бегает» пошустрее. Если опираться на время сборки полного набора пятых кед то:

Slackware-current собирает около 3.5 часов

LFS(BLFS\CLFS, а это собственно она) собрал меньше чем за 2 часа.

Вообще вся система (с пустого места до Plasma5 - 966 пакетов) компилится что-то около 5 часов.

Точнее не скажу, потому как специально не замерял.

ps\\ 966 пакетов это с учётом мультилиба(113 пакетов) они ещё часа полтора, самые «длинные» это qt5 (2часа), llvm (40 минут) и webkitgtk (тоже около часа)...

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

Не измерял. Даже если и прогоню тест, то сравнивать уже не с чем.

saahriktu ★★★★★ ()

Пусть компилирует g++ и считает логарифм через constexpr, тоже мне проблему нашёл.

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

Да у них там и так костыль был, что значит не хотят? http://lxr.free-electrons.com/source/include/linux/log2.h#L85

По факту они просто сделали объявление некоей функции ____ilog2_NaN http://lxr.free-electrons.com/source/include/linux/log2.h#L18 а саму функцию не написали, ну т.е. чтоб компилятор ругнулся, мол функции-то нет. Если туда вместо вызова этого ____ilog2_NaN запихнуть 1/0 то это тоже не скомпилируется, компилятор ругнется https://godbolt.org/g/pMz8wk

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

И да, если этот ilog2 с делением на ноль вместо ____ilog2_NaN применять к не-static переменным в функциях, то тогда ошибки компиляции уже не будет, но будет варнинг про деление на 0 https://godbolt.org/g/PKsXyj

Можно добавить еще немного костылей, и тогда оно даже и в таком случае даст ошибку компиляции

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

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

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

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

Вангую зоопарк различных версий шланга без каких-либо намёков на исходный код. Сейчас конечно зоопарк разных версий GCC, но зато все с исходным кодом.

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

Что-то надуманная у них проблема. Обязательно ли там нужна ошибка компиляции? Можно например на ноль поделить, варнинг будет

В ядре на ноль делить, самое то :)

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

секунду. до меня только сейчас дошло. а что, GCC 5 уже из беты вышел? у меня 4.9.4 стоит

+1 :)

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

Я уже почти год вручную даунгрейдю компилятор с дефолтного 6-го до 5-го :-)))
Вообще мне вся ета мулька с летящими версиями жутко не нравится. Что с кернелом что с ГЦЦ... Причем ладно бы просто версии летели, так реально же регулярно что-то меняется и нада корректировать.

Jetty ★★★★★ ()

Ну вот и отлично. Отловом багов тоже заниматься надо.

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

Как будто для твоих бинарных дистрибутивов собирают ядра не ментейнеры, а Святой Дух Торвальдса.

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