On Sun, 28 Nov 2021, Jeff Law wrote: > > > On 11/25/2021 6:33 AM, Richard Biener via Gcc-patches wrote: > > It seems to be a style to place gcc_unreachable () after a > > switch that handles all cases with every case returning. > > Those are unreachable (well, yes!), so they will be elided > > at CFG construction time and the middle-end will place > > another __builtin_unreachable "after" them to note the > > path doesn't lead to a return when the function is not declared > > void. > > > > So IMHO those explicit gcc_unreachable () serve no purpose, > > if they could be replaced by a comment. But since all cases > > cover switches not handling a case or not returning will > > likely cause some diagnostic to be emitted which is better > > than running into an ICE only at runtime. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu - any > > comments? > > > > Thanks, > > Richard. > > > > 2021-11-24 Richard Biener <rguent...@suse.de> > > > > * tree.h (reverse_storage_order_for_component_p): Remove > > spurious gcc_unreachable. > > * cfganal.c (dfs_find_deadend): Likewise. > > * fold-const-call.c (fold_const_logb): Likewise. > > (fold_const_significand): Likewise. > > * gimple-ssa-store-merging.c (lhs_valid_for_store_merging_p): > > Likewise. > > > > gcc/c-family/ > > * c-format.c (check_format_string): Remove spurious > > gcc_unreachable. > They would be a check if someone added a case to the switch that didn't > return. But we'd get a return-value warning if that happened. So I don't see > that they serve much purpose.
I've pushed the change. Richard.
