On 9/24/20 5:05 PM, Richard Biener wrote: > 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.
Ran into a build breaker after this commit, reported here ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97207 ). Thanks, - Tom
