This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] tree-ssa-dom.c: Use VEC(vrp_element_p,heap) instead ofVARRAY.
On Fri, 2005-05-06 at 15:26 -0400, Kazu Hirata wrote:
> Hi Jeff,
>
> > > > This doesn't look right to me. If you read the comments earlier in the
> > > > code it states that two tests must be performed. First you have to
> > > > verify the existance of the varray (or VEC) then you have to look at
> > > > the number of active entries.
> > > >
> > > > Your change will cause a segfault in the first case as *vrp_records
> > > > would be dereferencing a null pointer.
> > > >
> > > > So my question to you would be is there some reason why it's no longer
> > > > possible for vrp_records to be null?
> > >
> > > *vrp_records may be NULL, but VEC_length (vrp_element_p, NULL)
> > > evaluates to 0 because VEC_length is implemented as
> > You're misunderstanding me. I'm referring to vrp_records being null,
> > not *vrp_records.
> >
> > If vrp_records is null, then *vrp_records is going to segfault.
>
> Is your question about this hunk?
>
> @@ -2110,11 +2128,9 @@ simplify_cond_and_lookup_avail_expr (tre
> return NULL;
>
> vrp_hash_elt_p = (struct vrp_hash_elt *) *slot;
> - vrp_records = vrp_hash_elt_p->records;
> - if (vrp_records == NULL)
> - return NULL;
> + vrp_records = &vrp_hash_elt_p->records;
>
> - limit = VARRAY_ACTIVE_SIZE (vrp_records);
> + limit = VEC_length (vrp_element_p, *vrp_records);
>
> /* If we have no value range records for this variable, or we are
> unable to extract a range for this condition, then there is
>
> If that's the case, vrp_records could be NULL without my patch.
You're right. Stupidity leak on my part. Ignore my objections.
jeff