Skip to content

CWG2543 constinit and optimized dynamic initialization #1379

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jensmaurer opened this issue Dec 1, 2022 · 2 comments
Closed

CWG2543 constinit and optimized dynamic initialization #1379

jensmaurer opened this issue Dec 1, 2022 · 2 comments
Labels
CWG Core
Milestone

Comments

@jensmaurer
Copy link
Member

See CWG2543

CWG seeks the advice of EWG how to proceed with this issue.

Subclause 9.2.7 [dcl.constinit] paragraph 2 states:

If a variable declared with the constinit specifier has dynamic initialization (6.9.3.3 [basic.start.dynamic]), the program is ill-formed. [ Note: The constinit specifier ensures that the variable is initialized during static initialization (6.9.3.2 [basic.start.static]). —end note]

Subclause 6.9.3.2 [basic.start.static] paragraph 3 gives permission for an implementation to perform static initialization in lieu of dynamic initialization:

An implementation is permitted to perform the initialization of a variable with static or thread storage duration as a static initialization even if such initialization is not required to be done statically, provided that ...

constinit will assuredly not give a diagnostic for variables that are constant initialized (7.7 [expr.const] paragraph 2), because those are required to be statically initialized and thus will never be dynamically initialized. Conversely, constinit is guaranteed to give a diagnostic for variables that cannot be statically initialized, for example those with an initializer whose value depends on runtime conditions.

Between those boundaries, it is unclear whether constinit ought to give a diagnostic for variables whose initializer does not satisfy the constraints of constant-initialized, yet the implementation takes advantage of the permission to turn dynamic initialization into static initialization. For example,

  float f;
  constinit int * pi = (int*) &f;    // reinterpret_cast, not constant-initialized

The current wording seems to imply that constinit accurately reflects whether dynamic initialization was turned into static initialization by the implementation. However, that is impossible to implement, because such decisions are often made by the optimizer, which runs later than the compiler front-end interpreting the program text containing constinit.

There is value in permitting constinit not to diagnose some of the dynamic initializations that are turned into static initializations.

There is also value in having portable semantics of constinit.

@jensmaurer jensmaurer added the EWG Evolution label Dec 1, 2022
@erichkeane
Copy link
Collaborator

This was discussed at the Jan, 19, 2023 CWG Issues Review

And the following poll was taken:

EWG Agrees that we want portable, guaranteed semantics for constinit

SF F N A SA
8 3 2 0 0

Result: Strong Consensus

EWG wishes to encourage further work in the direction of extending static initialization to more cases.

SF F N A SA
1 5 6 1 0

Result: Not Consensus

@erichkeane erichkeane added CWG Core and removed EWG Evolution labels Jan 19, 2023
@jensmaurer jensmaurer added this to the 2023-02 milestone Jan 25, 2023
@jensmaurer
Copy link
Member Author

CWG 2023-02-06: Wording in CWG2543 approved by CWG; liaison discussion complete.

@jensmaurer jensmaurer added this to CWG Jul 15, 2024
@jensmaurer jensmaurer moved this to Ready for review in CWG Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CWG Core
Projects
Archived in project
Development

No branches or pull requests

2 participants