From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11484 invoked by alias); 22 Feb 2014 20:04:27 -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 11442 invoked by uid 48); 22 Feb 2014 20:04:24 -0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60314] [C++1y] ICE with decltype(auto) when generating debug information Date: Sat, 22 Feb 2014 20:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: NEW 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: cc 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/msg02394.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60314 Daniel Kr=C3=BCgler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.kruegler@googlemail. | |com --- Comment #2 from Daniel Kr=C3=BCgler --- Yes, it's valid C++14 as of the current draft. >>From gcc-bugs-return-444638-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Feb 22 20:09:25 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 13137 invoked by alias); 22 Feb 2014 20:09: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 13108 invoked by uid 48); 22 Feb 2014 20:09:20 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60320] New: Redundant static initialization check Date: Sat, 22 Feb 2014 20:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: glisse at gcc dot gnu.org 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: 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/msg02395.txt.bz2 Content-length: 1913 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60320 Bug ID: 60320 Summary: Redundant static initialization check Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, I think it would be nice if g++ realized that static variables that have been initialized don't later on become uninitialized again. A simple example: extern int e; static int b(){ static const int a = e; return a; } int g(){ return b()-b(); } gets "optimized" to: : _7 = MEM[(char *)&_ZGVZL1bvE1a]; if (_7 == 0) goto ; else goto ; : _8 = __cxa_guard_acquire (&_ZGVZL1bvE1a); if (_8 != 0) goto ; else goto ; : pretmp_26 = a; goto ; : e.2_9 = e; a = e.2_9; __cxa_guard_release (&_ZGVZL1bvE1a); : # prephitmp_27 = PHI _11 = MEM[(char *)&_ZGVZL1bvE1a]; if (_11 == 0) goto ; else goto ; : _12 = __cxa_guard_acquire (&_ZGVZL1bvE1a); if (_12 != 0) goto ; else goto ; : e.2_13 = e; a = e.2_13; __cxa_guard_release (&_ZGVZL1bvE1a); pretmp_5 = prephitmp_27 - e.2_13; : # prephitmp_3 = PHI <0(6), _12(7), pretmp_5(8), 0(2)> return prephitmp_3; There may be a dup but I couldn't find it. It doesn't seem that easy to teach gcc about it. Maybe LTO-inlining of __cxa_guard_* functions would help (or not). We could emit _ZGVZL1bvE1a=1 after the release call, but that seems ugly. We could have special code that, for a MEM_REF[&var42], looks for a dominating call to __cxa_guard_release(&var42), and in that case asserts it is non-zero (is that, or a slight variant, valid?).