From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24619 invoked by alias); 30 Oct 2013 10:16:53 -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 24575 invoked by uid 48); 30 Oct 2013 10:16:49 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/58920] Overeager optimization based on TREE_THIS_NOTRAP Date: Wed, 30 Oct 2013 10:16: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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org 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: 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: 2013-10/txt/msg02126.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58920 --- Comment #4 from Richard Biener --- (In reply to Eric Botcazou from comment #3) > > The TREE_THIS_NOTRAP macro came up in email the other day, and it seemed to > > me that it would be useful to set on C++ references, since they are required > > to refer to objects; trying to read from a null reference gives undefined > > behavior. So I tried the attached patch. But it breaks all the ext_pointer > > tests in libstdc++. > > > > Basically, what's happening is that there is a code path which is never > > taken which leads to an explicit null dereference. The optimizers see this > > happening within a loop and decide to hoist it out of the loop. So now it > > is executed before the loop starts, and causes a SEGV. > > If the dereference can generate a SEGV before being moved and nevertheless > has the TREE_THIS_NOTRAP flag, then this is the bug and loop invariant > motion does > not make things worse. > > As Andrew explained, you cannot set TREE_THIS_NOTRAP on all references. In > Ada, > we set it only on parameters passed by reference, but it needs to be cleared > during inlining because of this kind of issues. "This kind of issues" is that GCC treats TREE_THIS_NOTRAP as applying independent of the execution context. That is, if you have if (p) *p = 0; and mark *p with TREE_THIS_NOTRAP then GCC thinks *p will not trap even when moved before the if (p) check. So it has no concept of "conditionally doesn't trap". Though I thought that for C++ references that would be a non-issue. As of pointer vs. reference types this shouldn't matter here as you annotate actualy tcc_reference trees, not types.