https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot
com> ---
On Wed, 31 Aug 2016, manu at gcc dot gnu.org wrote:
> Code such as the following are suspicious:
>
> int foo(int a, int b)
> {
> return (a > 0 && a <= (b == 1) ? 1 : 2);
Actually I don't think this is suspicious at all; it's just an ordinary
conditional expression and this precedence rule doesn't tend to confuse
people normally. Certainly it's less dubious than various existing cases
warned about for precedence.
> Real bug in GCC: PR77421
>
> static void
> output_loc_operands (dw_loc_descr_ref loc, int for_eh_or_skip)
> {
> unsigned long die_offset
> = get_ref_die_offset (val1->v.val_die_ref.die);
> ....
> gcc_assert (die_offset > 0
> && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
> ? 0xffff
> : 0xffffffff);
I think the key thing that makes this suspicious is the boolean context
combined with both halves of the conditional expression being constant.
A conditional expression with both halves constant in a boolean context
either always evaluates to the same value, as here, or could be replaced
simply by "(COND)" or "(!(COND))".
Alternatively, a conditional expression in a boolean context where either
half is a constant that's not 0 or 1 is suspicious.
