On 2017.11.14 at 13:32 +0100, Richard Biener wrote: > 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.
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
