On Tue, Jul 12, 2016 at 04:42:21PM +0200, Bernd Schmidt wrote:
> On 07/12/2016 04:19 PM, Marek Polacek wrote:
> >
> >>>@@ -30191,6 +30200,7 @@ rs6000_adjust_cost (rtx_insn *insn, rtx link,
> >>>rtx_insn *dep_insn, int cost)
> >>> && (INSN_CODE (dep_insn) >= 0)
> >>> && (get_attr_type (dep_insn) == TYPE_MFFGPR))
> >>> return 2;
> >>>+ gcc_fallthrough ();
> >>>
> >>> default:
> >>> break;
> >>
> >>Better to put an extra "break" here. That is usually true if the next
> >>statement (after one or more labels) is a break.
> >
> >The next version of the warning should recognize this scenario and shouldn't
> >warn, thus no change will be needed.
>
> Actually I think this is one case where you could unconditionally warn -
> falling through to a break seems like bad practice, it invites errors when
> someone places new code before the break.
You get the warning when you place the new code there.
I think the falling into a case with only break; or falling into default:;}
is harmless.
Jakub
