This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 113d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-04-05


1986. odr-use and delayed initialization

Section: 6.9.3.2  [basic.start.static]     Status: drafting     Submitter: Richard Smith     Date: 2014-08-21

The current wording of 6.9.3.2 [basic.start.static] allows deferral of static and thread_local initialization until a variable or function in the containing translation unit is odr-used. This requires implementations to avoid optimizing away the relevant odr-uses. We should consider relaxing the rule to allow for such optimizations.

Proposed resolution (November, 2014):

For a variable V with thread or static storage duration, let X be the set of all variables with the same storage duration as V that are defined in the same translation unit as V. If the observable behavior of the abstract machine (6.7.2 [intro.object]) depends on the value of V through an evaluation E, and E is not sequenced before the end of the initialization of any variable in X, then the end of the initialization of all variables in X is sequenced before E.

There is also a problem (submitted by David Majnemer) if the odr-use occurs in a constexpr context that does not require the variable to be constructed. For example,

  struct A { A(); };
  thread_local A a;

  constexpr bool f() { return &a != nullptr; }

It doesn't seem possible to construct a before its odr-use in f.

There is implementation divergence in the handling of this example.

Notes from the November, 2014 meeting:

CWG determined that the second part of the issue (involving constexpr) is not a defect because the address of an object with thread storage duration is not a constant expression.

Additional note, May, 2015:

CWG failed to indicate where and how to apply the wording in the proposed resolution. In addition, further review has raised concern that “sequenced before” may be the wrong relation to use for the static storage duration case because it implies “in the same thread.”

Notes from the October, 2015 meeting:

The suggested wording is intended to replace some existing wording in 6.9.3.2 [basic.start.static] paragraph 2. CWG affirmed that the correct relationship is “happens before” and not “sequenced before.”