[Bug c++/18968] [4.0 regression] ICE: tree check: expected ssa_name, have addr_expr in vrp_hash

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From law at redhat dot com  2004-12-14 00:38 -------
Subject: Re:  [4.0 regression] ICE: tree check: expected
	ssa_name, have addr_expr in vrp_hash

On Mon, 2004-12-13 at 22:53 +0000, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-13 22:53 -------
> Though the front-end is at partial fault:
>   if (D.1739_9 != 0) goto <L0>; else goto <L1>;
> 
> 
> that 0 should be a pointer type, not an integer type so my fix is just a workaround for a C++ front-end 
> bug.
Agreed.

Let's take a looksie at what's going on.


  # BLOCK 2
  # PRED: 1 (true)
<L1>:;
  #   a_5 = V_MAY_DEF <a_4>;
  a.p = 0B;
  #   VUSE <a_5>;
  D.1651_6 = a.p;
  D.1652_7 = &D.1651_6->D.1579;
  if (D.1652_7 != 0) goto <L2>; else goto <L3>;
  # SUCC: 3 (true) 4 (false)


We replace a.p on the RHS of the assignment to D.1651_6 with 0B which
results in:

  # BLOCK 2
  # PRED: 1 (true)
<L1>:;
  #   a_5 = V_MAY_DEF <a_4>;
  a.p = 0B;
  #   VUSE <a_5>;
  D.1651_6 = 0B;
  D.1652_7 = &D.1651_6->D.1579;
  if (D.1652_7 != 0) goto <L2>; else goto <L3>;
  # SUCC: 3 (true) 4 (false)

So far so good.

We then replace D.1651_6 on the RHS of hte assignment to D.1652_7 with 
0B which results in:

  # BLOCK 2
  # PRED: 1 (true)
<L1>:;
  #   a_5 = V_MAY_DEF <a_4>;
  a.p = 0B;
  #   VUSE <a_5>;
  D.1651_6 = 0B;
  D.1652_7 = &0->D.1579;
  if (D.1652_7 != 0) goto <L2>; else goto <L3>;
  # SUCC: 3 (true) 4 (false)


So far, so good.  We then propagate &0->D.1579 into the use of D.1652_7
in the IF statement resulting in:

  # BLOCK 2
  # PRED: 1 (true)
<L1>:;
  #   a_5 = V_MAY_DEF <a_4>;
  a.p = 0B;
  #   VUSE <a_5>;
  D.1651_6 = 0B;
  D.1652_7 = &0->D.1579;
  if (&0->D.1579 != 0) goto <L2>; else goto <L3>;
  # SUCC: 3 (true) 4 (false)

Still OK.

The problem is that we consider the condition a range test because the
second argument is an integer type rather than a pointer test.

BTW, can we open a separate PR for the fact that we do not fold
&0->D.1579 down into a constant.  I doubt it matters a whole
lot, but it's rather silly not to fold &<0>->field down to the
byte offset of the field.


Jeff



-- 


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