Re: RFA (hash-map): PATCH to support GTY((cache)) with hash_map

[Markus Trippelsdorf <markus@trippelsdorf.de>]

On 2017.11.14 at 13:32 +0100, Richard Biener wrote:
> On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill <jason@redhat.com> wrote:
> > The hash_map interface is a lot more convenient than that of
> > hash_table for cases where it makes sense, but there hasn't been a way
> > to get the ggc_cache_remove behavior with a hash_map.  In other words,
> > not marking elements during the initial ggc marking phase, but maybe
> > marking them during the clear_caches phase based on keep_cache_entry.
> >
> > This patch implements that by:
> >
> > Adding a ggc_maybe_mx member function to ggc_remove, and overriding
> > that instead of ggc_mx in ggc_cache_remove.
> > Calling H::ggc_maybe_mx instead of H::ggc_mx in gt_ggc_mx (hash_table *).
> > Calling H::ggc_mx in gt_cleare_caches (hash_table *) rather than
> > relying on an extern declaration of a plain function that cannot be
> > declared for hash_map::hash_entry.
> > Adding ggc_maybe_mx and keep_cache_entry to hash_map::hash_entry.
> > Adding gt_cleare_cache for hash_map.
> > Adding a boolean constant to the hash-map traits indicating whether we
> > want the cache behavior above.
> >
> > I then define a typedef tree_cache_map to use this functionality, and
> > use it in a few places in the C++ front end.
> >
> > Tested x86_64-pc-linux-gnu, OK for trunk?
> 
> Ok.

The patch causes UB in some cases:
 
 gcc/hash-map.h:277:19: runtime error: member access within null pointer of type 'struct hash_map'

-- 
Markus