https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 18 Jun 2019, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904 > > --- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #1) > > I ran into a similar issue while trying > > > > hash_map <key, auto_vec<value, 2> > > > > > where copying fails to adjust the pointer to the in-place storage giving > > even more obscure errors. > > That's exactly what just happened to me. It has led to bizarre > miscompilations. How did you get around this? Use a plain vec and manage the > copying yourself? Yes, use a plain hash_map <key, vec<value> > and pay the price of one memory allocation per hash entry (the vec length is <= 1 in 95% of the cases for rpo_avail_t ...)
