Представленный фрагмент ничего не демонстрирует, от слова "вообще". Особенно, проблем с компилером. Единственное, что он демонстрирует, это лень и, как следствие, дурную манеру изложения, в стиле "Рабинович напел".

А кроме голословных утверждений Вам есть что сообщить? В чём именно заключается лень или дурные манеры?
Чтобы убедиться в том, а чём я пишу, достаточно:
1. Вставить в программу фрагмент кода (соответствующим образом изменив названия типов).
2. Откомпилировать. Убедиться, что начиная с условного оператора в листинге код не формируется, а предупреждений не выдается.
3. Поменять типы на int32u (или uint32_t, как удобно).
4. Снова откомпилировать,убедиться, что в листинге код есть, хотя результат условного оператора также предопределен, как и в первом случае.
5. Задуматься, возможно сделать выводы.
6. Если понятна причина такого поведения компилятора, рассказать автору вопроса.
7. Если причина неизвестна, то лучше промолчать, а не опускаться до стиля "сам дурак".

Стандарт С++. 5.3.1 Unary operators.
8 The operand of the unary - operator .....
Integral promotion is performed on integral or enumeration operands. .....
The type of the result is the type of the promoted operand.

Т.е. стандарт предписывает все целочисленные типы, а это харе-образные, с "int" и enum, расширять до знакового int и так далее в зависимости от размера.
Тип результата - расширенный операнд.
В случае с int16u результатом операции будет "signed int". Также как и ,например, результат операции (char) + (char) -> signed int;

Но вопрос Вы подняли правильно. Очень надеюсь, что найдутся разработчики компилятора, которые проигнорируют
маразматические моменты исторически сложившегося стандарта.

Сообщение отредактировал aiwa - May 7 2016, 08:00

Предлагаю один: не полагаться на компилятор /что он все приведения типов и приоритеты операций соблюдёт/
Расставляйте скобки и явные касты. (это не я придумал: жизнь учит)

Одноразовое изделие - одно, о нём и темы нет. Как только нужна переносимость кода весь геморрой - ваш.
Если соломку не стелить регулярно.
Темы о глюках компиляторов, стандартах и их (не)соблюдении вечны как и холивар.

Вообще то он СОБЛЮДЕТ! Лет 25 уже основные компиляторы сколь-нибудь явных ошибок НЕ допускают.

А вот это скоерее, да. Только НЕ для компилятора, а для себя, ибо в отличие от компилятора человку сложнее держать в голове те же 15 уровней приоритета.
Но и маниакально распихивать скобки и приведения типов тоже не дело.

Я все сообщил еще в своем первом ответе. И почему код отсутствует, и что запустить, что бы увидеть желаемое предупреждение.

Код, приведенный в первом посте - бессмысленный. С какой стати компилер должен предупреждать об этом? Это широко распространенный прием, например при условной компиляции, когда часть кода намеренно превращается бессмысленное. С какой стати компилеру лезть не в свое дело? Откуда он знает, это программер бестолково пишет, как в данном случае или код заточен под 100500 вариантов? А вот статический анализатор, тот не просто предупредит, вопить будет. Однако отсутствие вопросов и комментариев по статическому анализатору, говорит о том, что даже не понятно, о чем вообще речь. Так может, чем продолжать дерзить, запустить хоть раз C-STAT или хотя бы выяснить, что это такое?

Ну извините пожалуйста. Я сразу не обратил внимание, что Вы из Москвы. Простите молодого пятидесятилетнего провинциала, что я вообще вступил с Вами в дискуссию.
Мне надо было посыпать голову пеплом и с восторгом внимать Вам.
Только напомните мне пожалуйста, что именно Вы сказали по существу конкретного вопроса, который я задал?

Не понял, как это относится к запуску C-STAT, зато стало ясно, что имею дело с очередным не признанным гением. В этом месте позвольте откланяться. Удачи.

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

Как же Вы любите ярлыки навешивать... Вообще то мои слова появились в ответ на Ваше "продолжать дерзить".
По моему Вы вообще не поняли, о чём идёт речь.
1. Я не прошу помощи в написании кода или в оценке его качества.
2. Не нужно советов по использованию дополнительного ПО, так как это совсем не относится к делу.
3. И речь не шла о правильности или эффективности примера, его (примера) задача - продемонстрировать описанную проблему.
В своем сообщении я описал проблему в работе компилятора, которую увидел.
И хотел выяснить нормальное это поведение или нет и почему компилятор ведёт себя по разному в похожих случаях.
А конкретная задача в написании программы была решена ещё до того, как было написано сообщение.
Ведь не все вопросы обязаны быть на тему "помогите, не работает...".

Не знаю. Сколько компиляторов вы сделали? Я - ни одного. Потому и не знаю.

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

вы можете между собой договориться, есть в предписании стандарта речь про предупреждения или нет ?

А о чем должно быть предупреждение?
В сухом остатке получается переменная булевого типа, равная нулю. А само нарушение закона двойного отрицания происходит
в процессе обработки выражения.
Причем, в старых 16-битных компиляторах обработка происходит корректно.

Маразм процветает . Причем тут "старые", или "новые" - в огороде бузина а в Киеве дядька . Компиляция такого "примера" зависит от разрядности int целевой платформы и ни от чего более.