GCC 5 оптимизация, полная багов Опции

[Concorde]

Хотел бы поинтересоваться у людей - использует ли кто-нибудь GCC 5 при полной оптимизации в проектах ?
В gcc 5 (последний от launchpad) полно багов.
Вот ссылка на баг-репорт.
Есть ли смысл пробывать 4ю версию (или, может, другую 5ю ?).
Переехал недавно с IAR - просто в шоке.

[aaarrr]

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715]

Собирал ряд проектов для Cortex-M3/M4 и ARM926EJ. Всюду оптимизация -O2, багов нет.

[Genadi Zawidowsk...]

Использую последнюю ланчпадовскую сборку и с -Os и c -Ofast, cortex M3, M7, A9 (с TDM7 давно тестировал).
Везде проект ведёт себя предсказуемо...

arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fno-math-errno -funroll-loops -fgraphite -ffunction-sections -fdata-sections -ffat-lto-objects -Ofast -flto -gdwarf-2 -fomit-frame-pointer -Wall -Wstrict-prototypes -
DNDEBUG=1 -DCPUSTYLE_STM32F7XX=1 -DSTM32F746xx=1 -MD -MP -MF ./dep/bandfilters.o.d -I../../CMSIS-SP-00300-r4p5-00rel0/CMSIS/Include -I../ ../bandfilters.c -o bandfilters.o

arm-none-eabi-gcc -c -mcpu=cortex-a9 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -fno-math-errno -funroll-loops -fgraphite -ffunction-sections -fdata-sections -ffat-lto-objects -Ofast -flto -gdwarf-2 -fomit-frame-pointer -Wall -Wstrict-prototype
s -DNDEBUG=1 -DCPUSTYLE_R7S721=1 -DCPUSTYLE_R7S721020=1 -MD -MP -MF ./dep/bandfilters.o.d -I../ -I../rza1x_inc ../bandfilters.c -o bandfilters.o

Например так вызывается.

Сообщение отредактировал Genadi Zawidowski - Oct 17 2016, 21:57

[Concorde]

Собирал ряд проектов для Cortex-M3/M4 и ARM926EJ. Всюду оптимизация -O2, багов нет.

Не могли бы Вы протестить 'gcc_bug2.tar' (с баг-репорта) у себя ? Собственно, это я баг-репорты запостил.

[aaarrr]

Не могли бы Вы протестить 'gcc_bug2.tar' (с баг-репорта) у себя ? Собственно, это я баг-репорты запостил.

Уже Таки да, воспроизводятся оба.

[Concorde]

Уже Таки да, воспроизводятся оба.

Мне на этой неделе продукцию отгружать. С виду все работает (опустился до -O1), но коленки дрожат. Если ли смысл в срочном порядке переходить на 4.9 ?

[Aaron]

5й GCC такой профит мощный даёт, что не можете на 4.9 откатиться? Просто интересно. Сам сижу на GCC 4.9

[makc]

В 4.9 есть регрессии по размеру. В 5-ке не проверял, возможно вылечили.
Кроме того в 5-ке есть поддержка ARMv8-M, хотя не очень понятно зачем это может быть нужно сейчас.

[scifi]

Я использую 4.8 (в основном потому, что 4.9 немного раздувает размер кода, там и библиотека местами раздулась). Жду, когда смелые и безбашенные вроде вас найдут все глюки в новых версиях

[Concorde]

Оказался сам дурак (давненько не было проблем с оптимизацией).
Смотрите ответы.
Придется весь сторонний код как-то тестить и проверять и самому быть гораздо аккуратнее (оптимизация очень жесткой оказалась).

[Kabdim]

Качество кода lwip во всей красе, UB на UB и UB погоняет.
ЗЫ А варнинги это тоже пропустили?

[scifi]

Качество кода lwip во всей красе, UB на UB и UB погоняет.
ЗЫ А варнинги это тоже пропустили?

Я бы не стал вот так огульно. Этот баг был исправлен 3 мая 2012 года, то есть после выхода версии 1.4.0, но перед выходом 1.4.1. Кроме того, в обсуждении было сказано, что этот баг может вылезти только в том случае, если лёгкий выход за границу массива вдруг попадёт в защищённую область памяти и вызовет срабатывание защиты. Кто же мог предположить, что компилятор, увидев такое, воспримет это как индульгенцию генерировать чудо-юдо код? Я бы сказал, что это минус авторам gcc - в такой ситуации неплохо было бы хотя бы предупреждение выдать.
Кроме того, это говорит о пользе обновления до последнего релиза. В конце концов, есть надежда, что будет исправлено больше старых багов, чем добавлено новых

[Kabdim]

UB ж и есть индульгенция, по стандарту, так что gcc'шники полностью в своём праве. Впрочем раз исправили, значит отчасти и правда огульно.

[scifi]

UB ж и есть индульгенция, по стандарту, так что gcc'шники полностью в своём праве.

Если не выдали при этом предупреждение - это свинство. За такое в приличном обществе в харю трескают. А так да.
Допускаю, что алгоритмы оптимизации могут быть такими, что там непросто прицепить предупреждение. Но надо хотя бы попытаться

[k000858]

Опишите подробней плиз по-русски о чем речь (я так понимаю, какие то баги по части DHCP в lwip)
И что есть UB?

Сам пользую lwip 1.4.1 и GCC 5 с максимальной оптимизацией и как раз наблюдаю странное поведение ПО.

Сообщение отредактировал k000858 - Oct 19 2016, 05:50

[AHTOXA]

UB = undefined behavior.

[k000858]

Качество кода lwip во всей красе, UB на UB и UB погоняет.

въехать бы тебе в сакральный смысл данного поста

[Kabdim]

За UB в исходниках бьют канделябром известно куда, если автор в пределах доступности. Сакральный смысл - негодование за столь неопрятный стиль кодирования суть которого раскладывание грабель замедленного действия. С добавкой испуга от того что мог потратить свое время на это.
Ну и что бы не быть совсем флудером: What Every C Programmer Should Know About Undefined Behavior

[k000858]

ок. а в рамках обсуждаемого предмета (баг, я так понимаю в lwip который проявляется с GCC 5) можно разжевать что там к чему дабы не вдаваться в ассемблерный код?

[scifi]

ок. а в рамках обсуждаемого предмета (баг, я так понимаю в lwip который проявляется с GCC 5) можно разжевать что там к чему дабы не вдаваться в ассемблерный код?

При выходе за границу массива компилятор генерирует код, который не то, чтобы просто за границу массива выходит, а лезет в совершенно левые адреса.

[k000858]

При выходе за границу массива компилятор генерирует код, который не то, чтобы просто за границу массива выходит, а лезет в совершенно левые адреса.

Вот как раз что то подобное в паре проектов у себя наблюдаю...
только вот выходы за границу массивов не наблюдаю...

[Kabdim]

Если есть повторяемость где бьются данные, то всегда можно поставить watchpoint в нужное место и выяснить кто и где бьёт.

[Сергей Борщ]

Ну и что бы не быть совсем флудером: What Every C Programmer Should Know About Undefined Behavior

Прочитал. Долго втыкал в код

CODE

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Так и не понял, где тут ошибка.

This behavior enables an analysis known as "Type-Based Alias Analysis" (TBAA) which is used by a broad range of memory access optimizations in the compiler, and can significantly improve performance of the generated code. For example, this rule allows clang to optimize this function:

CODE

float *P;
void zero_array() {
   int i;
   for (i = 0; i < 10000; ++i)
     P[i] = 0.0f;
}

into "memset(P, 0, 40000)". This optimization also allows many loads to be hoisted out of loops, common subexpressions to be eliminated, etc. This class of undefined behavior can be disabled by passing the -fno-strict-aliasing flag, which disallows this analysis. When this flag is passed, Clang is required to compile this loop into 10000 4-byte stores (which is several times slower), because it has to assume that it is possible for any of the stores to change the value of P, as in something like this:

CODE

int main() {
  P = (float*)&P;  // cast causes TBAA violation in zero_array.
  zero_array();
}

Кто-то может объяснить?

Про переполнение знаковых целых как аргументов для функций выделения памяти - сами себе злобные Буратины: нафига размер передавать знаковой переменной? К тому же есть беззнаковый тип size_t. Но в целом да, раскрыты некоторые неочевидные вещи.

[Kabdim]

С оптимизацией в примере будет обнулен буфер 40КБ, начало которого совпадает с началом переменной P. Без оптимизации будет обнулен указатель, а последующие записи пойдут по адресам 0+i. Оба варианта конечно совершенно невменяемые, но примерам такое можно простить. В следующих частях мне показалось рассказывают еще интересней.

[Сергей Борщ]

Удалил. Понял.

[k000858]

кстати вся инфа актуальна только на оптимизации -Os?
или на -Og так же актуально?

[Kabdim]

Вот тут можно посмотреть что включают те или иные опции. Но это неправильный подход, правильный - в программе не должно быть UB точка.

[scifi]

Но это неправильный подход, правильный - в программе не должно быть UB точка.

Если не ошибаюсь, в этом случае lwip и не только он идут лесом. Слишком радикально, нет? Проще включить опцию -fno-strictaliasing.

[Kabdim]

Если выбор есть то лучше лесом, если нет то конечно придется терпеть и включать. Но нужно понимать что это сейчас достаточно включить no-strictaliasing. А потом может будет внедрена еще какая-нибудь оптимизация и грабля снова сработает, но уже так что будет совершенно неясно где корень зла. Или не сработает, как повезет.

[scifi]

А потом может будет внедрена еще какая-нибудь оптимизация и грабля снова сработает, но уже так что будет совершенно неясно где корень зла. Или не сработает, как повезет.

Нет. Слишком много написанного кода, который нельзя ломать. Всегда будет ключик, который это всё отключает.
Но да, надо следить за модой и писать как в лучших домах Лондона и Парижа. Чтобы потом деревенщиной не прозвали

[Concorde]

В случае с lwip (dhcp код, gcc_bug.tar):
Предупреждение не выдается с любыми флагами:
"-Wstrict-aliasing", "-Wstring-aliasing=1", "-Wstring-aliasing=2", "-Wstring-aliasing=3". Везде, кроме этого, есть ключ "-Wall".
Кстати, флаг "-fno-strict-aliasing" так же не помогает: начиная с "-O2" генерируется тот же "кривой" код.

[Сергей Борщ]

Испугался за lwIP. Полез в репозиторий. Это неопределнное поведение было устранено еще в мае 2012 года. Может стоит взять исходники посвежее, там и кучу других ошибок устранили за это время?

[Concorde]

Испугался за lwIP. Полез в репозиторий. Это неопределнное поведение было устранено еще в мае 2012 года. Может стоит взять исходники посвежее, там и кучу других ошибок устранили за это время?

Само собой.
Но речь сейчас идет о том, как такие проблемы поймать на этапе компиляции (в виде предупреждений). Выходит, никак (или я не знаю).

[Kabdim]

Позвольте все таки порекомендовать вам прочитать ту серию записей в 3 частях на который я ссылался. Во второй части описаны санитайзеры которые стоит применять. В третьей почему варининги для UB - плохая идея.

[scifi]

В третьей почему варининги для UB - плохая идея.

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

[Kabdim]

Отчего ж? Не может C++ компилятор статически полноценно проанализировать программу до исполнения. Соответственно, ложноположительных срабатываний будет запредельное кол-во при любом способе реализации. Ну а если хочется статического анализа, способ известен - rust-lang, энтузиасты его уже прикрутили к микроконтроллерам.

[scifi]

Отчего ж? Не может C++ компилятор статически полноценно проанализировать программу до исполнения.

Что значит "не может"? Пока не умеет. Вполне возможно, что со временем научится. Я никуда не тороплюсь

[Kabdim]

Если бы он мог, то UB как класса бы не существовало.

[scifi]

Если бы он мог, то UB как класса бы не существовало.

О господи.
Ещё раз, задача: выдавать предупреждение всякий раз, когда компилятор пользуется "неопределённым поведением" в целях оптимизации. Это чисто техническая задача. Автор той самой статьи честно признался, что он там будет ныть, как это всё непросто. Его аргументы сводились к тому, что сделать можно, просто геморройно. Кто бы сомневался.

[Kabdim]

Предлагаю эксперимент. Может воспользуйтесь всеми санитайзерами из 2 части на каком-нибудь большом уже написанном проекте и посчитайте кпд? У абстрактного всегда сообщателя о UB кпд будет примерно тот же, а число сообщений на порядок больше. Ну и какова будет ценность этого идеального сообщателя о UB? По сути идеальный сообщатель UB 1 в 1 копирует список примененных оптимизаций. И если варинги о смеси к примеру знаковых и беззнаковых переменных можно убрать принудительным приведением (сообщение от программиста компилятору "я знаю что тут происходит, всё будет хорошо"), то идеальный сообщатель о UB так "обмануть" не получится. Нужно будет абсолютно все переменные тщательно проверять на выход из границ везде. И где-то в этой точке должно стать очевидно что на какой-нибудь Аде/Яве/Шарпе такого софтового монстра запрограммировать проще быстрее и даже код выйдет вероятно эффективней. Чисто технически для плюсов с включенной оптимизацией это бесполезная задача.

[k000858]

я правильно понимаю, что ключ fno-strict-aliasing отключает эту самую оптимизацию по альязингу и снимает все эти негативные эффекты?