Re: [C++ PATCH] Avoid -Wreturn-type warnings if a switch has default label, no breaks inside of it, but is followed by a break (PR sanitizer/81275)

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Nov 27, 2017 at 07:49:41AM -0500, Nathan Sidwell wrote:
> On 11/25/2017 07:22 PM, Jakub Jelinek wrote:
> > On Sat, Nov 25, 2017 at 10:01:22AM +0100, Jakub Jelinek wrote:
> > > Actually, thinking about it some more, maybe it would be more efficient
> > > to gather this information during construction of the SWITCH_STMT in some
> > > new flag on the tree, so cxx_block_may_fallthru would just:
> > 
> > Here it is implemented, bootstrapped/regtested on x86_64-linux and
> > i686-linux, ok for trunk?
> 
> nice.
> 
> > --- gcc/cp/cp-tree.h.jj	2017-11-17 08:40:32.000000000 +0100
> > +++ gcc/cp/cp-tree.h	2017-11-25 21:25:48.277897180 +0100
> 
> > +/* Set if the body of a switch stmt contains a default: case label
> > +   and does not contain any break; stmts, thus if SWITCH_STMT_BODY
> > +   is not empty and doesn't fallthru, then the whole SWITCH_STMT
> > +   can't fallthru either.  */
> > +#define SWITCH_STMT_CANNOT_FALLTHRU_P(NODE) \
> > +  TREE_LANG_FLAG_0 (SWITCH_STMT_CHECK (NODE))
> 
> The macro name isn't quite right.  As the comment says, it's not sufficient
> that this flag is set for the switch to not fall through -- the switch body
> must be non-empty (which I presume it cannot be as there must be a default
> label), and it cannot fall through in its own right.

You are right that I can remove the || SWITCH_STMT_BODY (stmt) == NULL_TREE,
part, because then there wouldn't be any case labels in it either.

> The semantics of this flag are more like SWITCH_STMT_COVERS_ALL_CASES,
> perhaps something of that ilk would be a clearer name?

Well, that is only part of it.  Right now in the patch it does
  SWITCH_STMT_WITH_DEFAULT_WITHOUT_BREAK_P(NODE)

When not processing_template_decl, we could perhaps do better and have it
  SWITCH_STMT_COVERS_ALL_CASES_NO_BREAK_P(NODE),
because in that case we have the splay tree of all the case labels and we
could compute whether even without default: they cover all values.  Could
add that as a follow-up.

Any preference on the macro name then?

	Jakub