CWG 2024-10-11

Implementations have two options: Either a violation of an attribute causes an expressions not to be a constant expression, leading to runtime undefined behavior, or the attribute has no effect during constant evaluation.

Possible resolution:

1. Change in 7.7 [expr.const] paragraph 6:

   It is implementation-defined whether E is a core constant expression in the situations specified in 9.12.3 [dcl.attr.assume] and 9.12.11 [dcl.attr.noreturn].

   It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate

   • an operation that has undefined behavior as specified in Clause 16 [library] through Clause 34 [exec], or
   • an invocation of the va_start macro (17.13.2 [cstdarg.syn]),.
   • a call to a function that was previously declared with the noreturn attribute (9.12.11 [dcl.attr.noreturn]) and that call returns to its caller, or
   • a statement with an assumption (9.12.3 [dcl.attr.assume]) whose converted conditional-expression, if evaluated where the assumption appears, would not disqualify E from being a core constant expression and would not evaluate to true. [Note 5: E is not disqualified from being a core constant expression if the hypothetical evaluation of the converted conditional-expression would disqualify E from being a core constant expression. —end note]

2. Change in 9.12.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated.

   • If the converted expression would evaluate to true at the point where the assumption appears, the assumption has no effect.
   • Otherwise, if the statement with the assumption would be evaluated as part of an evaluation of an expression E that satisfies the constraints of a core constant expression (7.7 [expr.const]):
     • If the converted expression, evaluated at the point where the assumption appears, would disqualify E from being a core constant expression, the assumption is ignored.
     • Otherwise, it is implementation-defined whether E is a core constant expression; if E is evaluated as a core constant expression, the assumption has no effect.
   • Otherwise, the behavior is undefined.

3. Change in 9.12.11 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute and f eventually returns:

   • If the function call would be part of an evaluation of an expression E that satisfies the constraints of a core constant expression (7.7 [expr.const]), it is implementation-defined whether E is a core constant expression; if E is evaluated as a core constant expression, the attribute has no effect.
   • Otherwise, the behavior is undefined.

CWG 2024-09-27

The suggested resolution is circular with the rules in 7.7 [expr.const] paragraph 6.

Possible resolution:

1. Change in 9.12.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated. If the converted expression would evaluate to true at the point where the assumption appears, the assumption has no effect. Otherwise, outside of an evaluation to determine whether an expression is a core constant expression (7.7 [expr.const]), the behavior is undefined.

2. Change in 9.12.11 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute, the function call is evaluated outside of an evaluation to determine whether an expression is a core constant expression (7.7 [expr.const]), and f eventually returns, the behavior is undefined.

CWG 2024-09-13

Admitting unbounded core-language undefined behavior in constant expressions is to be avoided. The quoted note is correct; the semantics of [[noreturn]] and [[assume]] need to be clarified.

Possible resolution [SUPERSEDED]:

1. Change in 9.12.3 [dcl.attr.assume] paragraph 1 as follows:

   ... The expression is not evaluated. If the converted expression would evaluate to true at the point where the assumption appears or if the assumption is evaluated in a context that is manifestly constant-evaluated, the assumption has no effect. Otherwise, the behavior is undefined.

2. Change in 9.12.11 [dcl.attr.noreturn] paragraph 2 as follows:

   If a function f is called where f was previously declared with the noreturn attribute, the function call is evaluated in a context that is not manifestly constant-evaluated (7.7 [expr.const]), and f eventually returns, the behavior is undefined.

Suggested resolution [SUPERSEDED]:

Change in 3.63 [defns.undefined] as follows:

[Note 1 to entry: ... Evaluation of a constant expression (7.7 [expr.const]) never exhibits behavior explicitly specified as undefined in Clause 4 [intro] through Clause 15 [cpp], excluding 9.12 [dcl.attr]. —end note]

(From editorial issue #7042 and submission #595.)

Subclause 3.63 [defns.undefined] states:

[Note 1 to entry: ... Evaluation of a constant expression (7.7 [expr.const]) never exhibits behavior explicitly specified as undefined in Clause 4 [intro] through Clause 15 [cpp]. —end note]

However, 7.7 [expr.const] bullet 5.8 excludes [[noreturn]] and [[assume]]; see also 7.7 [expr.const] paragraph 6.