[basic.indet] P2795R5 vs. jumps across initialization of variables with vacuous initialization

[jakubjelinek]

Full name of submitter (unless configured in github; will be published with the issue): Jakub Jelinek

Reference (section label): [basic.indet]

Link to reflector thread (if any):

Issue description:

[stmt.dcl]/2 says it is valid to jump (say through switch or goto) across declaration of a variable with vacuous initialization.
With the P2795R5 introduction of erroneous behavior I don't see how it is implementable though, the prior art the paper mentiones (clang and gcc -ftrivial-auto-var-init={zero,pattern}) but those really don't ensure initialization in those cases (gcc even has -Wtrivial-auto-var-init warning to warn about cases like that). In my understanding the erroneous behavior requirement can be implemented by adding special magic initialization of the automatic variables, parameter slots if some non-trivial copy ctors (or other kinds of ctors) are invoked on those or temporary objects. So basically the standard asks for any variable declaration not to be vacuous anymore (in the implementation). But jumps across that initialization will still see uninitialized memory and so accesses to the vars with vacuous initialization across whose initialization code jumped will be still uninitialized and so still can't guarantee e.g. equality of multiple reads from that location resulting in the same value.
Consider:

struct S { S () = default; int a, b, c; };
void bar (S &, int &);

void
foo (int x)
{
  switch (x)
    {
    case 1:
      S a;
      a.a = 1; a.b = 2;
      int b;
      b = 3;
      bar (a, b);
      /* FALLTHRU */
    case 2:
      a.a = 4; a.b = 5;
      b = 6;
      bar (a, b);
      /* FALLTHRU */
    case 3:
      bar (a, b);
      break;
    case 4:
      goto end;
    default:
      break;
    }
  S c;
  int d;
  c.a = 7; c.b = 8;
  d = 9;
end:
  bar (c, d);
}

And another thing, I see [[indeterminate]] attribute being allowed only on parameter declarations of function declarations. That means one can opt-out for specific arguments to direct calls to the particular function. But shouldn't one be able to specify it also on for parameter declarations on function types as well, so that even virtual method calls or calls through function pointers etc. can opt-out of it?
Or does that open an unwanted pandorra box of taking the attributes into account for function type equality, having to mangle it etc.?

Suggested resolution:

[t3nsor]

I don't think that the current specification is unimplementable. It's just that, apparently, there is a lack of implementation experience for it. If a jump starts the lifetimes of variables with vacuous initialization, the implementation must ensure that the storage of those variables is initialized with values independent of the state of the program, and the cost of this is unknown.

[jakubjelinek]

Guess one could try to move the storage of the affected variables (vacuously initialized and jumped over) to a outer scope (up to the function body scope if needed, but also stop say at OpenMP/OpenACC construct body scopes) depending on from which scope it is jumped over and do the magic initialization at the start of such a scope. Though, it can't be marked dead at the end of its destructors in that case which would have very high costs for everything even when actually nothing jumps across it, because it can be e.g. inside of a loop body or with goto back before its declaration.
Or there could be just a flag variable moved to outer scope and keep it being set/cleared and magic initialize on demand. Guess for vars in SSA form it can be done pretty cheaply but for anything else it looks very costly.

[t3nsor]

It seems like one viable implementation strategy at least is that every forward jump that starts the lifetimes of variables with vacuous initialization performs the initializations with erroneous bytes for all such variables. In theory this could be very expensive but I think there's a chance that it isn't very expensive in practice. I suspect most C++ programmers very rarely write code that contains lifetime-starting forward jumps. It's more common in C, but still subject to the constraint that the more you're doing this, the harder the code is to read.

[jakubjelinek]

Indeed, compiler could turn all forward goto labX; which cross the same set of vacuous initializations into goto labX_; with
labX: preceded by if (0) { labX_: magic initialization of all those vars; } Perhaps even with multiple labels in the same block depending on what is jumped over