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.

Reply via email to