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.
