On Fri, Sep 15, 2017 at 11:45 PM, Jason Merrill <ja...@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. Richard.
