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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

UB = undefined behavior.

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

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

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

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

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

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

Прочитал. Долго втыкал в код
Так и не понял, где тут ошибка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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