[Bug c/97370] New: comedy of boolean errors for '!a & (b|c)'

[Bug c/97370] New: comedy of boolean errors for '!a & (b|c)'

[eggert at cs dot ucla.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370

            Bug ID: 97370
           Summary: comedy of boolean errors for '!a & (b|c)'
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

I ran into this problem while compiling a proposed patch for GNU grep.

For the following program a.c:

_Bool f (_Bool a, _Bool b, _Bool c) { return !a & (b|c); }
_Bool g (_Bool a, _Bool b, _Bool c) { return !(a) & (b|c); }
_Bool h (_Bool a, _Bool b, _Bool c) { return ~a & (b|c); }
_Bool i  (_Bool a, _Bool b, _Bool c) { return (b|c) & !a; }

The command 'gcc -Wall -S a.c' generates bogus diagnostics for 'f', 'g', and
'h' (see the diagnostics at the end of this comment).

* 'f' is incorrectly diagnosed even though it's the same thing as 'i' after
commuting the operands of '&'. ('i' is correctly allowed.)

* The diagnostic for 'f' suggests 'g', but 'g' produces the same diagnostic.

* The diagnostic for 'f' sugggests 'h', but 'h' produces a different
diagnostic. I understand why 'bool = ~bool' should be diagnosed (bug#77490),
but 'h' should not be diagnosed since 'bool & ~bool' always has the usual
boolean interpretation.

I finally ended up using the equivalent of 'i' in GNU grep, but I should have
been able to use any of 'f', 'g', or 'h' without worrying about generating a
bogus warning.

Here are the bogus diagnostics in question:
----

a.c: In function 'f':
a.c:1:46: warning: suggest parentheses around operand of '!' or change '&' to
'&&' or '!' to '~' [-Wparentheses]
    1 | _Bool f (_Bool a, _Bool b, _Bool c) { return !a & (b|c); }
      |                                              ^~
a.c: In function 'g':
a.c:2:46: warning: suggest parentheses around operand of '!' or change '&' to
'&&' or '!' to '~' [-Wparentheses]
    2 | _Bool g (_Bool a, _Bool b, _Bool c) { return !(a) & (b|c); }
      |                                              ^~~~
a.c: In function 'h':
a.c:3:46: warning: '~' on a boolean expression [-Wbool-operation]
    3 | _Bool h (_Bool a, _Bool b, _Bool c) { return ~a & (b|c); }
      |                                              ^
a.c:3:46: note: did you mean to use logical not?
    3 | _Bool h (_Bool a, _Bool b, _Bool c) { return ~a & (b|c); }
      |                                              ^
      |                                              !

[Bug c/97370] comedy of boolean errors for '!a & (b|c)'

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk <harald at gigawatt dot nl> ---
> * 'f' is incorrectly diagnosed even though it's the same thing as 'i' after commuting the operands of '&'. ('i' is correctly allowed.)

When an expression is written as !a & b, it is possible the user intended !(a &
b). If it is rewritten as b & !a, it is clear that the user did not intend !(b
& a).

> * The diagnostic for 'f' suggests 'g', but 'g' produces the same diagnostic.

Indeed, and that looks like a bad suggestion by GCC to me. The diagnostic for
'f' should be suggesting (!a) rather than !(a), which does manage to suppress
the diagnostic.

> * The diagnostic for 'f' sugggests 'h', but 'h' produces a different
diagnostic.

Although in general, informing the user that they may have wanted to use ~ may
be useful, I personally think that suggestion should be dropped if the operand
is of type _Bool/bool. You're correct that bool & ~bool will have the intended
result but my opinion is that that is overly clever code that hurts
readability, and GCC should not be offering that as a suggestion.

[Bug c/97370] comedy of boolean errors for '!a & (b|c)'

[eggert at cs dot ucla.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370

--- Comment #2 from eggert at cs dot ucla.edu ---
(In reply to Harald van Dijk from comment #1)

> When an expression is written as !a & b, it is possible the user intended
> !(a & b).

That's so unlikely as to not be worth worrying about. And even if it were more
likely, the same argument would apply to !a && b. Surely you're not suggesting
-Wparentheses should diagnose !a && b (that would generate many false alarms),
so -Wparentheses shouldn't diagnose !a & b either.

> You're correct that bool & ~bool will have
> the intended result but my opinion is that that is overly clever code that
> hurts readability, and GCC should not be offering that as a suggestion.

The GCC documentation says the motivation for warning about ~bool is that it's
very likely a bug in the program. This motivation does not apply to bool &
~bool, so it'd be better to not warn for that case. -Wbool-operation is
intended to diagnose likely bugs, not to diagnose "bad" style.

[Bug c/97370] comedy of boolean errors for '!a & (b|c)'

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370

--- Comment #3 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to eggert from comment #2)
> That's so unlikely as to not be worth worrying about.

See PR 7543 for the history of that warning.

> And even if it were
> more likely, the same argument would apply to !a && b.

A very significant difference is that !a && b is commonly seen where it is
exactly what the programmer wanted. For !a & b, that is not generally the case.

Perhaps the warning could be suppressed specifically for boolean variables,
since those make it more likely that the (!a) & b meaning is exactly what is
intended?

> The GCC documentation says the motivation for warning about ~bool is that
> it's very likely a bug in the program. This motivation does not apply to
> bool & ~bool, so it'd be better to not warn for that case.

Agreed. Apologies for the confusion there, I was trying to say I think the
suggestion to use ~ should be dropped, in which case the warning generated for
the ~ form becomes unrelated to your issue. I was not trying to say that the
warning generated for the ~ form should be kept.

[Bug c/97370] comedy of boolean errors for '!a & (b|c)'

[eggert at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370

Paul Eggert <eggert at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at gnu dot org

--- Comment #4 from Paul Eggert <eggert at gnu dot org> ---
(In reply to Harald van Dijk from comment #3)

> Perhaps the warning could be suppressed specifically for boolean variables,
> since those make it more likely that the (!a) & b meaning is exactly what is
> intended?

Yes, that's the idea. When a and b are booleans, !a & b has just one sensible
interpretation, and people are no more likely to get it wrong than to get -a +
b wrong. This distinguishes this case from the one discussed in PR 7543.