https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
--- Comment #4 from Rian Quinn <rianquinn at gmail dot com> --- Nope, I think that is the root of the issue. Where exactly does the spec state that as this is the first I have heard of this. Thanks a ton, - Rian On Mon, Jun 18, 2018 at 6:31 AM, redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189 > > Jonathan Wakely <redi at gcc dot gnu.org> changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > Status|UNCONFIRMED |WAITING > Last reconfirmed| |2018-06-18 > Ever confirmed|0 |1 > > --- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> --- > (In reply to Rian Quinn from comment #0) > > template <typename T1, typename T2> > > bool operator==(const myallocator4<T1> &, const myallocator4<T2> &) > > { return false; } > > > > template <typename T1, typename T2> > > bool operator!=(const myallocator4<T1> &, const myallocator4<T2> &) > > { return true; } > > Your allocators *always* compare unequal to all other instances of the same > allocator. This is invalid, a copy-constructed allocator must compare > equal to > the original, and be able to deallocate its memory. > > I haven't analysed any further, but I assume that the containers are using > a > copy to deallocate, which is perfectly fine. If you think the problem lies > elsewhere please reopen this. > > -- > You are receiving this mail because: > You reported the bug.