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.

Reply via email to