[Bug c++/103597] [12 Regression] False -Wimplicit-fallthrough= involving macro since r12-5638-ga3e75c1491cd2d50

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
-Wimplicit-fallthrough is performed on the freshly gimplified IL, so
cxx_block_may_fallthru is irrelevant to it.
And so it sees
  switch (n) <default: <D.1987>, case 0: <D.1980>, case 1: <D.1981>>
  <D.1980>:
  if (1 != 0) goto <D.1984>; else goto <D.1985>;
  <D.1984>:
  D.1986 = 0;
  // predicted unlikely by early return (on trees) predictor.
  return D.1986;
  <D.1985>:
  <D.1981>:
  D.1986 = 1;
  return D.1986;
  <D.1987>:
  D.1986 = 2;
  return D.1986;
where it sees that <D.1985>: falls through to <D.1981>: aka case 1:, and
because this is done before cfg is created, we can't cheaply go back and see
that D.1985 is only reachable from else of if (1).

What we could if we have a spare bit on LABEL_DECL or GIMPLE_LABEL is do
roughly what the C++ FE did previously in gimplify_cond_expr, but not through
actually not emitting that cond, but by setting a flag on the LABEL_DECL or
GIMPLE_LABEL that for the purposes of -Wimplicit-fallthrough warning we would
consider unreachable and set it on labels for COND_EXPR with integer_nonzerop
condition if !TREE_OPERANDS (expr, 2) || !TREE_SIDE_EFFECTS (TREE_OPERANDS
(expr, 2))
on the label_false label and if integer_zerop condition and
if !TREE_OPERANDS (expr, 1) || !TREE_SIDE_EFFECTS (TREE_OPERANDS (expr, 1))
on the label_true label.  Perhaps only do that for the freshly created
artificial labels though?
After gimplification of the COND_EXPR this is harder because we could have if
(1) { whatever; } else { ...; lab: ... } and goto lab;
from somewhere etc.
Unfortunately I'm not familiar enough with the -Wimplicit-fallthrough code, so
I can help with setting a flag in gimplify_cond_expr for labels that should be
ignored (i.e. we should act as if they weren't there, so when walking back look
at what is before them etc.).  Marek, could you please have a look?