------- 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
