So you say that Addrlen(0) and Addrlen(2) are proper constexprs?  Of course
Addrlen(1) is not.

> So you say that Addrlen(0) and Addrlen(2) are proper constexprs?  Of course
Addrlen(1) is not.

Yes. But GCC does not even allow to define the Addrlen function: https://godbolt.org/z/xqR2Lr

I guess that is because potential_constant_expression_1 punts on THROW_EXPR.  There is some code to not recurse if e.g. IF_STMT or COND_EXPR condition evaluates to constant zero or nonzero, but that is not the case here.
I actually don't know what in the standard requires something like potential_constant_expression{,_1} rather than just punting during constexpr evaluation if some non-constexpr construct is encountered.  For the cases listed in dcl.constexpr which may not show up in constexpr functions I thought that is covered in the parser already.

Also consider the equivalent(?)

constexpr foo() { throw 42; } // with or without constexpr

constexpr int Addrlen(int domain) {
    switch (domain) {
      case 0:
        return 0;
      case 2:
        return 42;
    }
    foo();
}

if Addrlen is allowed to be constexpr when foo() is not called
[and is not declared constexpr].  And whether foo may be declared
constexpr or not.

(In reply to Richard Biener from comment #4)
> Also consider the equivalent(?)
> 
> constexpr foo() { throw 42; } // with or without constexpr
> 
> constexpr int Addrlen(int domain) {
>     switch (domain) {
>       case 0:
>         return 0;
>       case 2:
>         return 42;
>     }
>     foo();
> }
> 
> if Addrlen is allowed to be constexpr when foo() is not called
> [and is not declared constexpr].  And whether foo may be declared
> constexpr or not.

foo cannot be constexpr, but no diagnostic is required:

> For a constexpr function or constexpr constructor that is neither defaulted nor a template, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression (7.7), or, for a constructor, a constant initializer for some object (6.8.3.2), the program is ill-formed, no diagnostic required.

Addrlen *can* be constexpr, because there are argument values that allow it to be evaluated at compile time, without ever reaching the throw (or reaching the call to the non-constexpr foo).

The bug is then in potential_constant_expression_1:
    case SWITCH_STMT:
      if (!RECUR (SWITCH_STMT_COND (t), rval))
        return false;
      /* FIXME we don't check SWITCH_STMT_BODY currently, because even
         unreachable labels would be checked.  */
      return true;

This is not conservatively correct as the testcases show.
The question is how much effort we do want to spend on that.

The simplest might be to add *jump_target = integer_zero_node; before the return true; above, that will just assume any switch can return and not check both the switch body (which isn't checked even now) nor anything after the switch.

Another option, slightly more involved, is say cp_walk_tree on SWITCH_STMT_BODY, looking for any RETURN_EXPRs or CONTINUE_STMTs (the latter only when not nested inside of a FOR_STMT, DO_STMT, WHILE_STMT and RANGE_FOR_STMT) and if we find a RETURN_EXPR, set jump_target to that, if we don't, but find a CONTINUE_STMT not nested in further looping constructs, set *jump_target to that CONTINUE_STMT, otherwise keep it unchanged.  To me this looks like the best approach for now.

Another option is try to do something for the case when SWITCH_STMT_COND is constant, but already for that we'd need to greatly extend the simplified:
  if (*jump_target)
    /* If we are jumping, ignore everything.  This is simpler than the
       cxx_eval_constant_expression handling because we only need to be
       conservatively correct, and we don't necessarily have a constant value
       available, so we don't bother with switch tracking.  */
    return true;
so that we do walk statements that can embed other statements like cxx_eval_constant_expression does and all of that stuff, with label_matches etc.

And if the above is done, we could have some also some mode in which for non-constant SWITCH_STMT_COND we could say set *jump_target to the SWITCH_STMT itself and treat it as a walk which walks the switch body, if it finds some CASE_LABEL_EXPR, it will change it to some other mode which will start processing all the expressions; if we detect something that is not a potential constant expression, we would at the level of whole stmts switch back to that *jump_target = SWITCH_STMT mode and keep looking for another CASE_LABEL_EXPR
and that way, if for any of the switch condition values there would be a potential constant expression, we'd succeed, otherwise fail, and even set jump_target properly based on that.  But this would be quite a lot of work.

Jason, any preferences here?

(I'd be interested in implementing one of the above, but would also like to hear from Jason first.)

(In reply to Jakub Jelinek from comment #6)
> Another option, slightly more involved, is say cp_walk_tree on
> SWITCH_STMT_BODY, looking for any RETURN_EXPRs or CONTINUE_STMTs (the latter
> only when not nested inside of a FOR_STMT, DO_STMT, WHILE_STMT and
> RANGE_FOR_STMT) and if we find a RETURN_EXPR, set jump_target to that, if we
> don't, but find a CONTINUE_STMT not nested in further looping constructs,
> set *jump_target to that CONTINUE_STMT, otherwise keep it unchanged.  To me
> this looks like the best approach for now.

I agree.

Created attachment 46027 [details]
gcc9-pr89785.patch

Untested fix.

Author: jakub
Date: Thu Mar 28 14:47:47 2019
New Revision: 269995

URL: https://gcc.gnu.org/viewcvs?rev=269995&root=gcc&view=rev
Log:
	PR c++/89785
	* constexpr.c (struct check_for_return_continue_data): New type.
	(check_for_return_continue): New function.
	(potential_constant_expression_1) <case SWITCH_STMT>: Walk
	SWITCH_STMT_BODY to find RETURN_EXPRs or CONTINUE_STMTs not nested
	in loop bodies and set *jump_target to that if found.

	* g++.dg/cpp1y/constexpr-89785-1.C: New test.
	* g++.dg/cpp1y/constexpr-89785-2.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89785-1.C
    trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89785-2.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/constexpr.c
    trunk/gcc/testsuite/ChangeLog

Fixed for 9.1+.