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.
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.
With my patch, vrp_records cannot be NULL because we have
slot = htab_find_slot (vrp_data, &vrp_hash_elt, NO_INSERT);
if (slot == NULL)
return NULL;
/* At this point, SLOT is nonnull. */
vrp_hash_elt_p = (struct vrp_hash_elt *) *slot;
/* At this point, VRP_HASH_ELT_P is nonnull. */
vrp_records = &vrp_hash_elt_p->records;
/* At this point, VRP_RECORDS is nonnull. */
limit = VEC_length (vrp_element_p, *vrp_records);
Kazu Hirata