В случае с 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 отключает эту самую оптимизацию по альязингу и снимает все эти негативные эффекты?