[Bug c/81484] incorrect -Wint-in-bool-context warning

["mpolacek at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Arnd Bergmann from comment #3)
> It seems I got a little confused when I only looked at the initial patch
> that was proposed, which was supposed to cover specifically the comparison
> followed by ?: as in
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00115.html. I see now that the
> patch that made it into the release also covers the more general case and
> that seems intentional, it just causes false-positive warnings.

I agree it's just a style warning here (to warn about if (c ? 0 : 2) I mean, as
that's correct code), but the warning allows you to simplify the code, so that
seems to be a good thing.

> The part that still seems odd here is that the warning does not take into
> account the macro: The caller just passes an expression as the integer
> argument into the setsign() macro, while the macro tests it for being
> nonzero.
> 
> In the opposite case, I found a piece of kernel code that does not produce a
> warning unless we preprocess it first (as ccache does for instance):
> 
> #define EINVAL 22
> #define v4l2_subdev_call(sd, f) ((sd)->f ? (sd)->f(sd) : -EINVAL)
> struct v4l2_subdev {
>         int (*g_sliced_fmt)(struct v4l2_subdev *sd);
> };
> int f(struct v4l2_subdev *sd)
> {
>         if (v4l2_subdev_call(sd, g_sliced_fmt))
>                 return -EINVAL;
> 
>         return 0;
> }
> 
> Here the macro contains the ?: operator while the caller contains the
> 'if()', and something in gcc seems to decide not to warn about this, but
> that logic does not identify the first example as an false-positive.

The warning checks whether the ?: expression comes from a macro.  If it does
(as in Comment 3), it doesn't warn.  But in the original testcase the ?: itself
is not coming from a macro so it warns.

I think I still don't see any bug here.