On 10/2/19 4:28 AM, Richard Biener wrote:
On Tue, Oct 1, 2019 at 8:50 PM Jason Merrill wrote:
On 10/1/19 3:34 AM, Richard Biener wrote:
On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
My comments accidentally got lost.
Several places in the front-end (and elsewhere) use the same lazy
On Tue, Oct 1, 2019 at 8:50 PM Jason Merrill wrote:
>
> On 10/1/19 3:34 AM, Richard Biener wrote:
> > On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
> >>
> >> My comments accidentally got lost.
> >>
> >> Several places in the front-end (and elsewhere) use the same lazy
> >> allocation patte
On 10/1/19 3:34 AM, Richard Biener wrote:
On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
My comments accidentally got lost.
Several places in the front-end (and elsewhere) use the same lazy
allocation pattern for hash_maps, and this patch replaces them with
hash_map_safe_* functions lik
On Mon, Sep 30, 2019 at 8:33 PM Jason Merrill wrote:
>
> My comments accidentally got lost.
>
> Several places in the front-end (and elsewhere) use the same lazy
> allocation pattern for hash_maps, and this patch replaces them with
> hash_map_safe_* functions like vec_safe_*. They don't provide a
My comments accidentally got lost.
Several places in the front-end (and elsewhere) use the same lazy
allocation pattern for hash_maps, and this patch replaces them with
hash_map_safe_* functions like vec_safe_*. They don't provide a way
to specify an initial size, but I don't think that's a signi
gcc/
* hash-map.h (default_size): Put in member variable.
(create_ggc): Use it as default argument.
(hash_map_maybe_create, hash_map_safe_get)
(hash_map_safe_get_or_insert, hash_map_safe_put): New fns.
gcc/cp/
* constexpr.c (maybe_initialize_fundef_copies_tab
