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

Reply via email to