On Tue, Jan 21, 2025 at 05:15:17PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2025 at 11:06:35AM -0500, Jason Merrill wrote:
> > > --- gcc/c-family/c-common.cc.jj 2025-01-20 18:00:35.667875671 +0100
> > > +++ gcc/c-family/c-common.cc 2025-01-21 09:29:23.955582581 +0100
> > > @@ -9010,33 +9010,46 @@ make_tree_vector_from_list (tree list)
> > > return ret;
> > > }
> > > -/* Get a new tree vector of the values of a CONSTRUCTOR. */
> > > +/* Append to a tree vector the values of a CONSTRUCTOR.
> > > + nelts should be at least CONSTRUCTOR_NELTS (ctor) and v
> > > + should be initialized with make_tree_vector (); followed by
> > > + vec_safe_reserve (v, nelts); or equivalently vec_alloc (v, nelts);
> > > + optionally followed by pushes of other elements (up to
> > > + nelts - CONSTRUCTOR_NELTS (ctor)). */
> >
> > How about using v->allocated () instead of passing in nelts?
>
> That is not necessarily the same.
> Both vec_safe_reserve (v, nelts) and vec_alloc (v, nelts); actually
> use exact=false, so they can allocate something larger (doesn't hurt
> e.g. if RAW_DATA_CST is small enough and fits), but if it used v->allocated
> (), it could overallocate from the overallocated size.
> So, e.g. even if nelts + RAW_DATA_LENGTH (x) - 1 <= v->allocated () -
> v->length ()
> and thus we could just use a vector without reallocating,
> v->allocated () + RAW_DATA_LENGTH (x) - 1 could be too much.
On the other side, if one uses v = vec_alloc (v, nelts) then v->allocated ()
is guaranteed to be MAX (4, nelts) and if one uses v = make_tree_vector ();
vec_safe_reserve (v, nelts); then v->allocated () will be I think at most
MAX (24, nelts).
So perhaps not that big deal (at least if the function inside of it uses
unsigned nelts = v->allocated (); and then uses nelts rather than
v->allocated () in the loop. Unless some new caller of the function uses
a vector reallocated more times.
Jakub
