On Tue, 2017-06-20 at 14:01 -0400, Jason Merrill wrote:
> On Tue, Jun 20, 2017 at 1:58 PM, Jason Merrill <ja...@redhat.com>
> wrote:
> > On Tue, Jun 20, 2017 at 11:50 AM, David Malcolm <
> > dmalc...@redhat.com> wrote:
> > > > + ob->next_free = p + type_start + type_len;
> >
> > I'm uncomfortable with modifying the obstack directly. Why not use
> > obstack_free?
>
> ...because you aren't freeing the object, but shrinking it. So
> obstack_blank is a better choice.
Thanks.
As of r229987 ("Copy gnulib obstack files", aka
1ed1385ecb1c11d6915adac74afa2ff7da8be5d1),
libiberty/obstacks.texi says:
> @cindex shrinking objects
> You can use @code{obstack_blank_fast} with a ``negative'' size
> argument to make the current object smaller. Just don't try to
> shrink it beyond zero length---there's no telling what will happen
> if you do that. Earlier versions of obstacks allowed you to use
> @code{obstack_blank} to shrink objects. This will no longer work.
It's not clear to me what the issue alluded to with negative
obstack_blank is, but I chose to follow the above docs and use
obstack_blank_fast; am testing an updated patch in which the above line
now looks like:
obstack_blank_fast (ob, -(type_start + type_len));
Is the patch OK with that change? (assuming bootstrap®rtesting
pass), or should I re-post?
On a related matter, this patch conflicts with Volker's patch here:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01576.html
in which he removes the trailing "{enum}" info (and hence all of our
changes to the testsuite conflict between the two patches...)
Do you have any thoughts on that other patch? [Ccing Volker]
Thanks
Dave
