From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-428152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25465 invoked by alias); 21 Aug 2013 08:49:22 -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
Received: (qmail 25417 invoked by uid 48); 21 Aug 2013 08:49:21 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
Date: Wed, 21 Aug 2013 08:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57393-4-wWpSixJXLR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57393-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57393-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: 2013-08/txt/msg01076.txt.bz2

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

--- Comment #20 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yes, the patch maybe fixes the debuginfo issue, but there's something else that
is wrong.  E.g., on the testcase from PR58018, we have in reassociate_bb
*after*
(and that is important) optimize_range_tests this:

<bb 7>:
[...]
e.1_16 = _14 & e.0_15;
_17 = f_12 >= 0;
_18 = (int) _17;
e.1_19 = e.1_16 & _18;
_20 = f_12 > 0;
_23 = f_12 > 0;
_24 = (int) _23;
_21 = (int) _20;
e.1_22 = e.1_19 & _21;
[...]

Now, in reassociate_bb, we go over the stmts, from the last stmt to the first
stmt in the bb.  For the appropriate stmts, we call rewrite_expr_tree to
rewrite the linearized statements according to the operand_entry_t ops vector,
in this case we call it on
  e.1_22 = e.1_19 & _21;
and the vector ops contains
  Op 0 -> rank: 589826, tree: _14
  Op 1 -> rank: 3, tree: _24
  Op 2 -> rank: 1, tree: e.0_15

In rewrite_expr_tree, we recursively call this function on e.1_19, whose
SSA_NAME_DEF_STMT is
  e.1_19 = e.1_16 & _18;
This stmt is then transformed into
  e.1_19 = _24 & e.0_15;

But, at the point where e.1_19 is defined, the _24 isn't defined yet!

So, it seems, ensure_ops_are_available should handle a situation like this. 
However, it doesn't: perhaps the issue is that find_insert_point won't find the
right insert point (the stmt is e.1_19 = e.1_16 & _18;, the dep_stmt is _24 =
(int) _23;), in there we have:

  if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt)
      && gimple_bb (insert_stmt) == gimple_bb (dep_stmt)
      && insert_stmt != dep_stmt)
    insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt);
  else if (not_dominated_by (insert_stmt, dep_stmt))
    insert_stmt = dep_stmt;
  return insert_stmt;

Neither of these condition holds; gimple_uid of the dep_stmt is 0 and of
insert_stmt it is 16.  Thus, find_insert_point returns e.1_19 = e.1_16 & _18;. 
That's wrong, I suppose.
Maybe the issue is that if the two stms are in the same bb, we just look at
their UIDs and based on that we find out the dependency, but the new stms
coming  from optimize_range_tests don't have gimple UIDs set, thus this can't
work.
Likely I'm wrong, would appreciate if someone could shed some light on this.

Looking into it more...