[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

["vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165

--- Comment #15 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
> GCC only sees the first case. The analysis that GCC performs are predicated
> on the transformations leading to better code, otherwise they are not
> performed. A tool for static analysis will surely inline as much as it
> could, not matter if the code is slower or larger, but this is not how GCC
> works because GCC is not a tool for static analysis.

Well, detecting uninitialized variables is equivalent to generating better
code. See the following functions. If you want to be able to remove the i == 0
test in the first one (making generated code better), you'll solve the warning
problem in the second one.

int f(void)
{
  int i = 0;
  /* some code that sets i to a nonzero value, but difficult to prove */
  if (i == 0)
    abort();
  return i;
}

int f(void)
{
  int i;
  /* some code that sets i to a nonzero value, but difficult to prove */
  return i;
}
>From gcc-bugs-return-443471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 13:59:25 2014
Return-Path: <gcc-bugs-return-443471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18799 invoked by alias); 13 Feb 2014 13:59:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18773 invoked by uid 48); 13 Feb 2014 13:59:21 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/60174] ICE on ACATS cc3305a
Date: Thu, 13 Feb 2014 13:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60174-4-yzfgZ8Dft0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60174-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60174-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg01228.txt.bz2
Content-length: 1821

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`174

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Richard Biener from comment #1)
> Can you check from the -fdump-tree-all dumps where i_34(ab) and i_399(ab)
> start to have overlapping life-ranges?

OK, i used grep 'i_\(34\|399\)(ab)' cc3305a.adb.*

i_399(ab) is first mentioned in cc3305a.adb.078t.dom1:

cc3305a.adb.078t.dom1:i_399(ab) -> { i_36(ab) }
cc3305a.adb.078t.dom1:  # i_34(ab) = PHI <i_168(D)(ab)(2), i_168(D)(ab)(3),
i_168(D)(ab)(4), i_398(ab)(8), i_398(ab)(9), i_398(ab)(11), i_398(ab)(12),
i_398(ab)(13), i_35(ab)(14), i_35(ab)(15), i_35(ab)(16), i_35(ab)(17),
i_208(ab)(20), i_208(ab)(21), i_208(ab)(22), i_399(ab)(25), i_399(ab)(26),
i_399(ab)(28), i_399(ab)(30), i_399(ab)(31), i_36(ab)(32), i_36(ab)(34),
i_36(ab)(36), i_36(ab)(38), i_400(ab)(39), i_37(ab)(41), i_37(ab)(42),
i_37(ab)(43), i_38(ab)(46), i_38(ab)(47), i_38(ab)(48), i_401(ab)(51),
i_401(ab)(52), i_401(ab)(54), i_401(ab)(56), i_401(ab)(57), i_39(ab)(58),
i_39(ab)(60), i_43(ab)(90), i_402(ab)(61), i_40(ab)(63), i_40(ab)(64),
i_40(ab)(65), i_41(ab)(68), i_41(ab)(69), i_41(ab)(70), i_403(ab)(73),
i_403(ab)(74), i_403(ab)(76), i_403(ab)(78), i_403(ab)(79), i_42(ab)(80),
i_42(ab)(82), i_42(ab)(84), i_42(ab)(86), i_404(ab)(87), i_43(ab)(89)>
cc3305a.adb.078t.dom1:  # i_399(ab) = PHI <i_36(ab)(24), i_333(93)>
cc3305a.adb.078t.dom1:  _188 = i_399(ab) != 0;
cc3305a.adb.078t.dom1:  _189 = i_399(ab) != 4;
cc3305a.adb.078t.dom1:  # i_400(ab) = PHI <i_399(ab)(29), i_36(ab)(37),
i_36(ab)(38), i_399(ab)(30)>
cc3305a.adb.078t.dom1:  # i_305 = PHI <i_34(ab)(5)>
cc3305a.adb.078t.dom1:  # i_333 = PHI <i_34(ab)(23)>
cc3305a.adb.078t.dom1:  # i_350 = PHI <i_34(ab)(49)>
cc3305a.adb.078t.dom1:  # i_365 = PHI <i_34(ab)(71)>

is this already overlapping?