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.
Bernd
