https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's difficult, see the recent discussion on introducing explicit live-in
markers for the purpose of stack slot sharing and exactly these case of
testcases.
The "simplest" suggestion was to promote the variable to an outer scope when
such entry into the containing scope is detected. But since we are doing
auto-init at gimplification time the new point of initializaton would need to
be computed before somehow.
Since you are getting a diagnostic which we could even improve to
warning: variable auto-init for `x' will never be executed
and you do like to get auto-init and you _can_ fix your code that's all
perfectly OK.
Yes, there might be a way to compute auto-init locations (! yes, multiple,
with obvious code-size impact) or a more conservative location (extending
the variable lifetime with the corresponding effect on stack slot sharing).
But clearly fixing the source is prefered. Mind that when you write
int g(int *);
int f1()
{
switch (0) {
int x = 0;
default:
return g(&x);
}
}
you get the very same effect. So IMHO -ftrivial-auto-var-init behaves
_exactly_ as one would assume it would, without doing any invisible
magic dances.
So yes, let's improve the diagnostic to be specific about each variable
that is not initialized (and maybe the following still unreachable stmt).
