https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- (In reply to Manuel López-Ibáñez from comment #9) > It seems to me that they are two different warnings that could be triggered > on similar code. The one warned by the patch would also warn about: > > if (a ? 1 : 2) > > but not about > > gcc_assert (die_offset > 0 > && die_offset <= (loc->dw_loc_opc == DW_OP_call2) > ? 0 > : 0xffffffff); > > nor: > > gcc_assert (die_offset > 0 > && die_offset <= (loc->dw_loc_opc == DW_OP_call2) > ? n > : 0xffffffff); > > This is what clang emits for a similar case (for which GCC does not warn): > > prog.cc:3:26: warning: operator '?:' has lower precedence than '<<'; '<<' > will be evaluated first [-Wparentheses] > int n = a << (a == b) ? 1 :2; > ~~~~~~~~~~~~~ ^ > prog.cc:3:26: note: place parentheses around the '<<' expression to silence > this warning > int n = a << (a == b) ? 1 :2; > ^ > ( ) > prog.cc:3:26: note: place parentheses around the '?:' expression to evaluate > it first > int n = a << (a == b) ? 1 :2; > ^ > ( ) > > > Perhaps a middle-ground would be something like: > > warning: operator '?:' has lower precedence than '=='; '==' will be > evaluated first and '?:' will evaluate to integers in boolean context > [-Wparentheses] > if (a == b ? 1 : 2) > ~~~~~~ ^ > note: place parentheses around the '==' expression to silence this warning > if (a == b ? 1 : 2) > ~~~~~~ > (a == b) > note: place parentheses around the '?:' expression to evaluate it first > if (a == b ? 1 : 2) > ~~~~~~~~~ > (b ? 1 : 2) I think normal C code like: int x = a == b ? 1 : 2; should not trigger a -Wall warning. Maybe -Wextra, but even -Wextra does not enable everything we have. Probably because of too much false positives? But the warning on << at LHS of ?: will rarely have false positives. I mean << makes really no sense in a truth value context. For instance assume a is int; then, I can show that: "if (a << b)" would be the same as "if (a)", because << has undefined behaviour on overflow. If the user writes "<< b" then that should not be undefined nor redundant. The same logic that's behind my patch. "if (a ? 1 : 2)" evaluates to "if (1)" and that's something that can't be right, as an assertion that is written with 4 lines of ?: expression, but it's evaluated to "if (0)" by the FE.