This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] let hash-based containers work with non-trivial types (PR 90923)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin Sebor <msebor at gmail dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Fri, 21 Jun 2019 14:06:29 +0200
- Subject: Re: [PATCH] let hash-based containers work with non-trivial types (PR 90923)
- References: <email@example.com>
On Wed, Jun 19, 2019 at 5:15 AM Martin Sebor <firstname.lastname@example.org> wrote:
> Bug 90923 shows that even though GCC hash-table based containers
> like hash_map can be instantiated on types with user-defined ctors
> and dtors they invoke the dtors of such types without invoking
> the corresponding ctors.
> It was thanks to this bug that I spent a day debugging "interesting"
> miscompilations during GCC bootstrap (in fairness, it was that and
> bug 90904 about auto_vec copy assignment/construction also being
> hosed even for POD types).
> The attached patch corrects the hash_map and hash_set templates
> to invoke the ctors of the elements they insert and makes them
> (hopefully) safe to use with non-trivial user-defined types.
Hum. I am worried about the difference of assignment vs. construction
+ bool ins = hash_entry::is_empty (*e);
+ if (ins)
+ e->m_key = k;
+ new ((void *) &e->m_value) Value (v);
+ e->m_value = v;
why not invoke the dtor on the old value and then the ctor again?
How is an empty hash_entry constructed? ::remove() doesn't
seem to invoke the dtor either, instead it relies on the
> Tested on x86_64-linux.