From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 78876385840A; Mon, 14 Feb 2022 07:26:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78876385840A
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize
 a variable, causes a spurious warning
Date: Mon, 14 Feb 2022 07:26:33 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102276-4-pj9RLEtmDz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102276-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102276-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Feb 2022 07:26:33 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102276

--- 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 =3D 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).=