This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Move hash-table.h and related files to libiberty
On Sat, Sep 21, 2019 at 7:41 AM Richard Biener
> On September 21, 2019 12:28:57 PM GMT+02:00, Christian Biesinger <firstname.lastname@example.org> wrote:
> >On Sat, Sep 21, 2019 at 7:22 PM Richard Biener
> ><email@example.com> wrote:
> >> On September 21, 2019 11:12:38 AM GMT+02:00, Christian Biesinger via
> >gcc-patches <firstname.lastname@example.org> wrote:
> >> >Hello,
> >> >
> >> >I would like to move hash-table.h, hash-map.h and related files
> >> >to libiberty, so that GDB can make use of it.
> >> >
> >> >I see that gcc already has a C++ file in include/ (unique-ptr.h),
> >> >which I understand is libiberty.
> >> >
> >> >However, this patch is not complete yet (for a start, it doesn't
> >> >compile). Before I go further down this road, is this acceptable
> >> >in principle to the gcc/libiberty maintainers?
> >> >
> >> >(the bulk of the patch is including vec.h in a lot of files,
> >> >because hash-table.h previously included it. It doesn't
> >> >actually use it, and I didn't think it was necessary to
> >> >move that to libiberty as well, so I removed that include
> >> >and instead am adding it to all the files that now don't
> >> >compile.)
> >> The bulk seems to be hash_table to hash_table_ggc renaming. Can you
> >Yeah, sure. If hash-table.h lives in libiberty, I wanted to reduce the
> >dependencies on other headers. GCC's garbage collector seems like
> >something that does not belong there, so I moved this create function
> >to a separate header, which required renaming it since it now can't be
> >part of the same class. (the other option would be some kind of #ifdef
> >GCC thing, but that seemed ugly to me)
> As long as gengtype can still pick up everything correctly via the GTY annotations that's probably OK.
OK, I've decided to give up on this project for now -- there are too
many GCC dependencies in this file. But I may try forking the file for