[Bug tree-optimization/22630] New: vrp produces wrong code

[Bug tree-optimization/22630] New: vrp produces wrong code

[belyshev at depni dot sinp dot msu dot ru]

// C testcase, compile with -O2
// reduced from mozilla crashes in javascript library

void abort (void);

int j;

void bla (int *r)
{
  int *p, *q;

  p = q = r;
  if (!p)
    p = &j;
  
  if (p != q)
    j = 1;
}

int main (void)
{
  bla (0);
  if (!j)
    abort ();
  return 0;
}

-- 
           Summary: vrp produces wrong code
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: critical
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: belyshev at depni dot sinp dot msu dot ru
                CC: dnovillo at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
                    dot org


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

[Bug tree-optimization/22630] vrp produces wrong code

[belyshev at depni dot sinp dot msu dot ru]

------- Additional Comments From belyshev at depni dot sinp dot msu dot ru  2005-07-23 16:35 -------
started to fail between "2005-06-02 00:20 UTC" and "2005-06-03 00:20 UTC"

-- 


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-23 16:36 -------
Confirmed.
For some reason we fold:
Folding predicate p_1 != r_2 to 0
Folded statement: if (p_1 != r_2) goto <L2>; else goto <L3>;
            into: if (0) goto <L2>; else goto <L3>;

p_1: ~[0B, 0B]  EQUIVALENCES: { r_2 } (1 elements)
r_2: VARYING
q_3: [r_2, r_2]  EQUIVALENCES: { r_2 } (1 elements)
p_4: [r_2, r_2]  EQUIVALENCES: { r_2 } (1 elements)
r_7: ~[0B, 0B]  EQUIVALENCES: { r_2 } (1 elements)

  # p_1 = PHI <r_7(5), &j(1)>;
<L1>:;

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-23 16:36:51
               date|                            |
            Summary|vrp produces wrong code     |[4.1 Regression] vrp
                   |                            |produces wrong code
   Target Milestone|---                         |4.1.0


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-23 16:38 -------
Caused almost likely by:
+2005-06-01  Diego Novillo  <dnovillo@redhat.com>
+
+       PR 14341, PR 21332, PR 20701, PR 21029, PR 21086, PR 21090
+       PR 21289, PR 21348, PR 21367, PR 21368, PR 21458.

-- 


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2005-07-25 00:35 -------
Calling vrp_evaluate_condition with use_equiv_p = false in tree-ssa-propagate.c
could fix this problem.

-- 


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[law at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |law at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-07-27 16:21 -------
Fixed by the attached patch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[ja2morri at csclub dot uwaterloo dot ca]

------- Additional Comments From ja2morri at csclub dot uwaterloo dot ca  2005-07-27 16:34 -------
Subject: Re:  [4.1 Regression] vrp produces
 wrong code


Jeffrey A Law <law@redhat.com> writes:

> The underlying problem here is the code to meet a VR_ANTI_RANGE and
> a VR_RANGE does not intersect the equivalence sets.  This in turn
> causes the VRP code to incorrectly evaluate a conditional.  It's
> all downhill after that.
>
> While investigating this problem I also noticed that the vrp_meet
> code does not properly handle intersecting the equivalence sets
> when vr0 has a set, but vr1 does not (their intersection is the
> null set of course).  This patch fixes that oversight as well.
>
> Bootstrapped and regression tested on i686-pc-linux-gnu.
>
> jeff

 You added 3 bitmap_clear calls here, do you have any testcases that
exercise this code?



-- 


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

[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-07-27 16:55 -------
Subject: Re:  [4.1 Regression] vrp produces
	wrong code

On Wed, 2005-07-27 at 16:34 +0000, ja2morri at csclub dot uwaterloo dot
ca wrote:
> ------- Additional Comments From ja2morri at csclub dot uwaterloo dot ca  2005-07-27 16:34 -------
> Subject: Re:  [4.1 Regression] vrp produces
>  wrong code
> 
> 
> Jeffrey A Law <law@redhat.com> writes:
> 
> > The underlying problem here is the code to meet a VR_ANTI_RANGE and
> > a VR_RANGE does not intersect the equivalence sets.  This in turn
> > causes the VRP code to incorrectly evaluate a conditional.  It's
> > all downhill after that.
> >
> > While investigating this problem I also noticed that the vrp_meet
> > code does not properly handle intersecting the equivalence sets
> > when vr0 has a set, but vr1 does not (their intersection is the
> > null set of course).  This patch fixes that oversight as well.
> >
> > Bootstrapped and regression tested on i686-pc-linux-gnu.
> >
> > jeff
> 
>  You added 3 bitmap_clear calls here, do you have any testcases that
> exercise this code?
No, but the code is clearly wrong by inspection.  

jeff




-- 


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