On Thu, 24 Sep 2020, Jonathan Wakely wrote: > On 24/09/20 11:11 +0200, Richard Biener wrote: > >On Wed, 26 Aug 2020, Richard Biener wrote: > > > >> On Thu, 6 Aug 2020, Richard Biener wrote: > >> > >> > On Thu, 6 Aug 2020, Richard Biener wrote: > >> > > >> > > This adds a move CTOR to auto_vec<T, 0> and makes use of a > >> > > auto_vec<edge> return value for get_loop_exit_edges denoting > >> > > that lifetime management of the vector is handed to the caller. > >> > > > >> > > The move CTOR prompted the hash_table change because it appearantly > >> > > makes the copy CTOR implicitely deleted (good) and hash-table > >> > > expansion of the odr_enum_map which is > >> > > hash_map <nofree_string_hash, odr_enum> where odr_enum has an > >> > > auto_vec<odr_enum_val, 0> member triggers this. Not sure if > >> > > there's a latent bug there before this (I think we're not > >> > > invoking DTORs, but we're invoking copy-CTORs). > >> > > > >> > > Bootstrap / regtest running on x86_64-unknown-linux-gnu. > >> > > > >> > > Does this all look sensible and is it a good change > >> > > (the get_loop_exit_edges one)? > >> > > >> > Regtest went OK, here's an update with a complete ChangeLog > >> > (how useful..) plus the move assign operator deleted, copy > >> > assign wouldn't work as auto-generated and at the moment > >> > there's no use of assigning. I guess if we'd have functions > >> > that take an auto_vec<> argument meaning they will destroy > >> > the vector that will become useful and we can implement it. > >> > > >> > OK for trunk? > >> > >> Ping. > > > >Ping^2. > > Looks good to me as far as the use of C++ features goes.
Thanks, now pushed after re-testing. Richard.
