From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1343 invoked by alias); 13 Feb 2014 13:48:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1267 invoked by uid 48); 13 Feb 2014 13:48:18 -0000 From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2 Date: Thu, 13 Feb 2014 13:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-gcc at vinc17 dot net 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: In-Reply-To: References: 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-SW-Source: 2014-02/txt/msg01227.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60165 --- Comment #15 from Vincent Lef=C3=A8vre -= -- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 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 predicat= ed > 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 = =3D=3D 0 test in the first one (making generated code better), you'll solve the warn= ing problem in the second one. int f(void) { int i =3D 0; /* some code that sets i to a nonzero value, but difficult to prove */ if (i =3D=3D 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=60174 --- Comment #3 from Bernd Edlinger --- (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 cc3305a.adb.078t.dom1: # i_399(ab) = PHI 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 cc3305a.adb.078t.dom1: # i_305 = PHI cc3305a.adb.078t.dom1: # i_333 = PHI cc3305a.adb.078t.dom1: # i_350 = PHI cc3305a.adb.078t.dom1: # i_365 = PHI is this already overlapping?