From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-231040-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10560 invoked by alias); 30 Sep 2007 14:01:26 -0000
Received: (qmail 10497 invoked by alias); 30 Sep 2007 14:01:11 -0000
Date: Sun, 30 Sep 2007 14:01:00 -0000
Message-ID: <20070930140111.10496.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-33572-8535@http.gcc.gnu.org/bugzilla/>
Subject: [Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
In-Reply-To: <bug-33572-8535@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
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
X-SW-Source: 2007-09/txt/msg02488.txt.bz2



------- Comment #12 from rguenther at suse dot de  2007-09-30 14:01 -------
Subject: Re:  [4.3 Regression] wrong code with
 -O

On Sun, 30 Sep 2007, dnovillo at google dot com wrote:

> > ------- Comment #9 from rguenth at gcc dot gnu dot org  2007-09-30 12:41 -------
> > Diego, we seem to have a general problem with the incremental SSA updater.
> > If we rename foo$ptr in
> >
> > <bb 6>:
> >   # foo$ptr_16 = PHI <foo$ptr_18(ab)(5), D.1758_3(4)>
> >   p_12 = foo$ptr_16;
> >   foo$ptr_19(ab) = 0B;
> >   p_15 = foo$ptr_16;
> >   p_4 = foo$ptr_16;
> >   p_5 = foo$ptr_16;
> >   D.1781_6 = foo$ptr_16->_vptr.Foo;
> >   D.1782_7 = *D.1781_6;
> >   OBJ_TYPE_REF(D.1782_7;foo$ptr_16->0) (foo$ptr_16);
> >   goto <bb 8>;
> 
> Is the symbol foo$ptr being marked for renaming?  If so, that's wrong.
>  A gimple register symbol cannot be marked for renaming if there are
> overlapping live ranges in its SSA names.  We don't have a general
> mechanism to prevent that.  Mostly because we do not keep track when
> OLRs are created.  The generic SSA updating mechanism has no cheap way
> of checking that.

Yes, it is marked for renaming by the inliner.  Somehow the inliner
assumes there are no OLRs:

...
   The function mark PHI_RESULT of such PHI nodes for renaming; it is
   safe the EH edges are abnormal and SSA_NAME_OCCURS_IN_ABNORMAL_PHI
   must be set.  This means, that there will be no overlapping live ranges
   for the underlying symbol.

   This might change in future if we allow redirecting of EH edges and
   we might want to change way build CFG pre-inlining to include
   all the possible edges then.  */

static void
update_ssa_across_eh_edges (basic_block bb)
{
  edge e;
  edge_iterator ei;

  FOR_EACH_EDGE (e, ei, bb->succs)
    if (!e->dest->aux
        || ((basic_block)e->dest->aux)->index == ENTRY_BLOCK)
      {
        tree phi;

        gcc_assert (e->flags & EDGE_EH);
        for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
          {
            gcc_assert (SSA_NAME_OCCURS_IN_ABNORMAL_PHI
                        (PHI_RESULT (phi)));
            mark_sym_for_renaming
              (SSA_NAME_VAR (PHI_RESULT (phi)));
          }
      }
}


-- 


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