https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #17 from Jonathan Wakely ---
Done:
https://gitlab.com/esr/gcc-conversion/merge_requests/47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #16 from Jonathan Wakely ---
It had nothing to do with Git. It's just a python script that says commit
r279763 is related to PR x not PR y.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #15 from Thomas Koenig ---
(In reply to Jonathan Wakely from comment #14)
> And please also fix the comment in the new test.
(In reply to Jonathan Wakely from comment #13)
> (In reply to Thomas Koenig from comment #12)
> > (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #14 from Jonathan Wakely ---
And please also fix the comment in the new test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #13 from Jonathan Wakely ---
(In reply to Thomas Koenig from comment #12)
> (In reply to Thomas Koenig from comment #11)
>
> *sigh* corrected in the original PR.
Please add a 'fixup' to the bugdb.py file in the gcc-conversion repo,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Mon Dec 30 10:43:38 2019
New Revision: 279763
URL: https://gcc.gnu.org/viewcvs?rev=279763=gcc=rev
Log:
Remove KIND argument from INDEX so it does not mess up scalarization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #10 from Jonathan Wakely ---
I don't think it's possible to construct an example where this would misbehave.
If allocator_traits::is_always_equal is true for X then it implies that
operator== will return true for all values of X,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > This might strictly conform to the requirements, but it's stupid. Why would
> > you do that?
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #7 from Jonathan Wakely ---
I can't believe that this has ever caused a real problem, or ever will cause a
real problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #6 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
>
> And the noexcept exceptions provided in the current implementations are
> really inconsistent, for instance, between move operator= of std::list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
> This might strictly conform to the requirements, but it's stupid. Why would
> you do that?
>
> Allocator equality doesn't care about the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #4 from Jonathan Wakely ---
This might strictly conform to the requirements, but it's stupid. Why would you
do that?
Allocator equality doesn't care about the value type, as evidenced by the
requirement that a==b is equivalent to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #3 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to frankhb1989 from comment #0)
>
> This type does not meet the allocator requirements. For a valid allocator,
> A::rebind::other must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #2 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #0)
> Case:
>
> #include
> #include
> #include
> #include
>
> struct A : std::allocator>
> {
> template
> struct rebind
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #1 from frankhb1989 at gmail dot com ---
Allocator-extended constructors with explicit exception specifications may also
have the value_type/node mismatch problems.
17 matches
Mail list logo
