public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits
@ 2012-11-20  8:51 benjamin.kircher at gmail dot com
  2012-11-20  9:13 ` [Bug libstdc++/55409] " redi at gcc dot gnu.org
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: benjamin.kircher at gmail dot com @ 2012-11-20  8:51 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

             Bug #: 55409
           Summary: std::list not properly wrapping access to custom
                    allocator through allocator_traits
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: benjamin.kircher@gmail.com


Created attachment 28741
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28741
Small example showing simple custom allocator with std::list and std::vector

The attached source file compiles fine with a std::vector as container_type.
Using std::list however, compilation fails with the error message given below.
Expected behavior is that it compiles with std::list as like with std::vector.

$ gcc --version
gcc (Debian 4.7.2-4) 4.7.2


$ cat main.cpp
template<typename T> class my_alloc
{
    // class template supporting the minimal interface according to 17.6.3.5
};

int main()
{
    //typedef std::vector<int, my_alloc<int>> container_type;
    typedef std::list<int, my_alloc<int>> container_type;
    container_type cont;
    cont.push_back(11);
    cont.push_back(22);
    cont.push_back(33);
    return 0;
}


$ g++ -g -std=c++11 -Wall -Wextra -pedantic main.cpp
<snip>
/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class std::list<int,
my_alloc<int> >’:
main.cpp:56:20:   required from here
/usr/include/c++/4.7/bits/stl_list.h:449:58: error: no type named ‘pointer’ in
‘std::list<int, my_alloc<int> >::_Tp_alloc_type {aka class my_alloc<int>}’
/usr/include/c++/4.7/bits/stl_list.h:450:58: error: no type named
‘const_pointer’ in ‘std::list<int, my_alloc<int> >::_Tp_alloc_type {aka class
my_alloc<int>}’
/usr/include/c++/4.7/bits/stl_list.h:451:58: error: no type named ‘reference’
in ‘std::list<int, my_alloc<int> >::_Tp_alloc_type {aka class my_alloc<int>}’
/usr/include/c++/4.7/bits/stl_list.h:452:58: error: no type named
‘const_reference’ in ‘std::list<int, my_alloc<int> >::_Tp_alloc_type {aka class
my_alloc<int>}’
<snip>
and so on.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
@ 2012-11-20  9:13 ` redi at gcc dot gnu.org
  2012-11-20  9:25 ` redi at gcc dot gnu.org
                   ` (13 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2012-11-20  9:13 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-20 09:13:36 UTC ---
This is known and documented.  I'm actually working on std::list next, but I
don't know if it will be done for 4.8 or not.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
  2012-11-20  9:13 ` [Bug libstdc++/55409] " redi at gcc dot gnu.org
@ 2012-11-20  9:25 ` redi at gcc dot gnu.org
  2012-11-20  9:31 ` benjamin.kircher at gmail dot com
                   ` (12 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2012-11-20  9:25 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-20 09:24:53 UTC ---
N.B. the minimal allocator interface requires operator== and operator!=, and 
max_size and rebind are not required.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
  2012-11-20  9:13 ` [Bug libstdc++/55409] " redi at gcc dot gnu.org
  2012-11-20  9:25 ` redi at gcc dot gnu.org
@ 2012-11-20  9:31 ` benjamin.kircher at gmail dot com
  2012-11-20 10:30 ` redi at gcc dot gnu.org
                   ` (11 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: benjamin.kircher at gmail dot com @ 2012-11-20  9:31 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #3 from Benjamin Kircher <benjamin.kircher at gmail dot com> 2012-11-20 09:31:07 UTC ---
Thank you for working on it and for the remark.

NB: For the next time, where can I find the documentation?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (2 preceding siblings ...)
  2012-11-20  9:31 ` benjamin.kircher at gmail dot com
@ 2012-11-20 10:30 ` redi at gcc dot gnu.org
  2014-09-02 19:11 ` freddie_chopin at op dot pl
                   ` (10 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2012-11-20 10:30 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-20
     Ever Confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-20 10:30:32 UTC ---
in the manual
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
"Only vector meets the requirements relating to allocator use and propagation."

and the release notes for 4.7
http://gcc.gnu.org/gcc-4.7/changes.html
"vector meets the allocator-aware container requirements"

In GCC 4.8 std::forward_list is also allocator-aware, but I haven't updated the
release notes yet.

Confirming but don't hold your breath for it to be fixed in 4.8


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (3 preceding siblings ...)
  2012-11-20 10:30 ` redi at gcc dot gnu.org
@ 2014-09-02 19:11 ` freddie_chopin at op dot pl
  2014-09-03  4:27 ` redi at gcc dot gnu.org
                   ` (9 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: freddie_chopin at op dot pl @ 2014-09-02 19:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Freddie Chopin <freddie_chopin at op dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |freddie_chopin at op dot pl

--- Comment #5 from Freddie Chopin <freddie_chopin at op dot pl> ---
Any news on that bug? I just hit the same problem as the author, so I'm
wondering whether anyone's working on that or maybe I could help a little bit?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (4 preceding siblings ...)
  2014-09-02 19:11 ` freddie_chopin at op dot pl
@ 2014-09-03  4:27 ` redi at gcc dot gnu.org
  2014-09-03  6:35 ` freddie_chopin at op dot pl
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-03  4:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm working on it


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (5 preceding siblings ...)
  2014-09-03  4:27 ` redi at gcc dot gnu.org
@ 2014-09-03  6:35 ` freddie_chopin at op dot pl
  2014-09-03 11:20 ` redi at gcc dot gnu.org
                   ` (7 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: freddie_chopin at op dot pl @ 2014-09-03  6:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #7 from Freddie Chopin <freddie_chopin at op dot pl> ---
Great (; Do you have some timeline? I'm not trying to rush you - I'm just
working on a project in which this feature would be beneficial, so I'm
wondering whether I should wait a bit (this particular requirement is not
top-priority) or maybe just implement the allocator "the old way" for now.

Thanks in advance!


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (6 preceding siblings ...)
  2014-09-03  6:35 ` freddie_chopin at op dot pl
@ 2014-09-03 11:20 ` redi at gcc dot gnu.org
  2015-04-10 14:42 ` redi at gcc dot gnu.org
                   ` (6 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2014-09-03 11:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It will be done for the GCC 5.0 release.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (7 preceding siblings ...)
  2014-09-03 11:20 ` redi at gcc dot gnu.org
@ 2015-04-10 14:42 ` redi at gcc dot gnu.org
  2015-04-10 14:42 ` redi at gcc dot gnu.org
                   ` (5 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2015-04-10 14:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Minimal test:

#include <list>

template<typename T> class my_alloc
{
public:
    typedef T value_type;

    T* allocate(size_t n)
    { return std::allocator<T>::allocate(n); }

    void deallocate(T* ptr, size_t n)
    { std::allocator<T>::deallocate(ptr, n); }

    my_alloc() = default;
    template<typename U> my_alloc(const my_alloc<U>&) noexcept {}
};

template<typename T>
bool operator==(const my_alloc<T>&, const my_alloc<T>&) { return true; }

template<typename T>
bool operator!=(const my_alloc<T>&, const my_alloc<T>&) { return false; }

int main()
{
    typedef std::list<int, my_alloc<int>> container_type;
    container_type cont;
    cont.push_back(11);
}


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (8 preceding siblings ...)
  2015-04-10 14:42 ` redi at gcc dot gnu.org
@ 2015-04-10 14:42 ` redi at gcc dot gnu.org
  2015-06-16 16:29 ` redi at gcc dot gnu.org
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2015-04-10 14:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Target Milestone|5.0                         |6.0

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This didn't happen, I'll try to get it done for 5.2


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (9 preceding siblings ...)
  2015-04-10 14:42 ` redi at gcc dot gnu.org
@ 2015-06-16 16:29 ` redi at gcc dot gnu.org
  2015-06-17 20:37 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2015-06-16 16:29 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |potswa at mac dot com

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 66559 has been marked as a duplicate of this bug. ***


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (10 preceding siblings ...)
  2015-06-16 16:29 ` redi at gcc dot gnu.org
@ 2015-06-17 20:37 ` redi at gcc dot gnu.org
  2015-06-17 21:20 ` potswa at mac dot com
                   ` (2 subsequent siblings)
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2015-06-17 20:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Wed Jun 17 20:36:42 2015
New Revision: 224580

URL: https://gcc.gnu.org/viewcvs?rev=224580&root=gcc&view=rev
Log:
C++11 allocator support for std::list.

        PR libstdc++/55409
        * include/bits/list.tcc (_List_base::_M_clear()): Use allocator traits.
        (list::list(const list&)): Use allocator propagation trait. Use
        _M_assign_dispatch to copy elements.
        * include/bits/stl_list.h (_List_node): Use __aligned_membuf in C++11.
        (_List_node::_M_valptr()): Add accessor for stored value.
        (_List_iterator, _List_const_iterator, _List_base): Use _M_valptr().
        (_List_base, list): Use allocator traits.
        (_List_base::_M_get_Tp_allocator, _List_base::get_allocator): Remove.
        (_List_base::_M_move_nodes): New function.
        (_List_base(_List_base&&)): Use _M_move_nodes.
        (_List_base(_List_base&&, _Node_alloc_type&&)): New constructor.
        (list::_M_create_node, list::_M_erase, list::max_size): Use allocator
        traits.
        (list(size_type)): Add allocator parameter.
        (list(const list&)): Use allocator propagation trait.
        (list(const list&, const allocator_type&)): New constructor.
        (list(list&&, const allocator_type&)): Likewise.
        (list::operator=(list&&), list::swap(list&)): Use allocator
        propagation traits.
        (list::_M_move_assign): New functions.
        * include/debug/list: Add allocator-extended constructors.
        * include/profile/list: Likewise.
        * python/libstdcxx/v6/printers.py (get_value_from_list_node): New
        function to get value from _List_node.
        (StdListPrinter): Use get_value_from_list_node.
        * testsuite/23_containers/list/allocator/copy.cc: New.
        * testsuite/23_containers/list/allocator/copy_assign.cc: New.
        * testsuite/23_containers/list/allocator/minimal.cc: New.
        * testsuite/23_containers/list/allocator/move.cc: New.
        * testsuite/23_containers/list/allocator/move_assign.cc: New.
        * testsuite/23_containers/list/allocator/noexcept.cc: New.
        * testsuite/23_containers/list/allocator/swap.cc: New.
        * testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
        Adjust dg-prune-output line number.
        * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc:
        Likewise.
        * testsuite/23_containers/list/requirements/dr438/insert_neg.cc:
        Likewise.

Added:
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/copy.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/copy_assign.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/minimal.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/move.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/move_assign.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/noexcept.cc
    trunk/libstdc++-v3/testsuite/23_containers/list/allocator/swap.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/list.tcc
    trunk/libstdc++-v3/include/bits/stl_list.h
    trunk/libstdc++-v3/include/debug/list
    trunk/libstdc++-v3/include/profile/list
    trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
   
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (11 preceding siblings ...)
  2015-06-17 20:37 ` redi at gcc dot gnu.org
@ 2015-06-17 21:20 ` potswa at mac dot com
  2015-06-17 22:20 ` potswa at mac dot com
  2015-09-10 20:30 ` redi at gcc dot gnu.org
  14 siblings, 0 replies; 16+ messages in thread
From: potswa at mac dot com @ 2015-06-17 21:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #13 from David Krauss <potswa at mac dot com> ---
Nice!

Just a few things:

1. Line 304: rebind isn’t an official member of allocator_traits. Prefer
rebind_alloc.

2. _M_put_node is assuming no fancy pointers: its parameter is a
_Node_alloc_traits::pointer but its argument is a _Node*. I think the intent
with fancy pointers is that they get stored in nodes, but doing so would change
the ABI for fancy pointers that implicitly convert to raw. Perhaps that’s
acceptable, with these sweeping changes?

3. Line 554: should call _Node_alloc_traits::construct. (This breaks allocators
which need a rebind to do construction, but so does the C++11 standard. To be
both backward- and forward-compatible would require rebinding, converting,
constructing via traits, converting back, and assigning. According to my
reading, anyway.) For what it’s worth, the revision already uses
_Node_alloc_traits::destroy, although that’s customized less in practice.
>From gcc-bugs-return-489255-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 17 21:58:44 2015
Return-Path: <gcc-bugs-return-489255-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28597 invoked by alias); 17 Jun 2015 21:58:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28246 invoked by uid 48); 17 Jun 2015 21:58:39 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
Date: Wed, 17 Jun 2015 21:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55409-4-q4D1d8eYF7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55409-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55409-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01587.txt.bz2
Content-length: 2043

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Krauss from comment #13)
> 1. Line 304: rebind isn’t an official member of allocator_traits. Prefer
> rebind_alloc.

That isn't allocator_traits, it's __gnu_cxx::__alloc_traits, which is a
compatibility layer that works the same in C++03 and C++11. It has rebind, not
rebind_alloc, see <ext/alloc_traits.h>

> 2. _M_put_node is assuming no fancy pointers: its parameter is a
> _Node_alloc_traits::pointer but its argument is a _Node*. I think the intent
> with fancy pointers is that they get stored in nodes,

I agree it's desirable, but it's not really clear that it's required, see
http://cplusplus.github.io/LWG/lwg-active.html#2261

> but doing so would
> change the ABI for fancy pointers that implicitly convert to raw. Perhaps
> that’s acceptable, with these sweeping changes?

These changes shouldn't affect the ABI. 

I have patches coming some time for fancy pointers in all containers, for
PR57272, which also don't affect the ABI. My plan is to use the existing node
types for allocators without fancy pointers, but use a new family of types
(_List_ptr_node, _List_ptr_iterator etc.) that use fancy pointers. That will
preserve ABI compatibility for non-fancy pointers, but also fully support fancy
pointers. But it's a lot of work, due to the backward-compatibility
requirements.

> 3. Line 554: should call _Node_alloc_traits::construct. (This breaks
> allocators which need a rebind to do construction, but so does the C++11
> standard. To be both backward- and forward-compatible would require
> rebinding, converting, constructing via traits, converting back, and
> assigning. According to my reading, anyway.) For what it’s worth, the
> revision already uses _Node_alloc_traits::destroy, although that’s
> customized less in practice.

Line 504 is only compiled in C++98 mode, where allocators are required to
provide a construct member.
>From gcc-bugs-return-489256-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 17 22:18:18 2015
Return-Path: <gcc-bugs-return-489256-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62259 invoked by alias); 17 Jun 2015 22:18:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 62231 invoked by uid 48); 17 Jun 2015 22:18:14 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
Date: Wed, 17 Jun 2015 22:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57272-4-SN8u1B8vsa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57272-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57272-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01588.txt.bz2
Content-length: 176

https://gcc.gnu.org/bugzilla/show_bug.cgi?idW272

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
c.f. http://cplusplus.github.io/LWG/lwg-active.html#2261


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (12 preceding siblings ...)
  2015-06-17 21:20 ` potswa at mac dot com
@ 2015-06-17 22:20 ` potswa at mac dot com
  2015-09-10 20:30 ` redi at gcc dot gnu.org
  14 siblings, 0 replies; 16+ messages in thread
From: potswa at mac dot com @ 2015-06-17 22:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

--- Comment #15 from David Krauss <potswa at mac dot com> ---
> On 2015–06–18, at 5:58 AM, redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> These changes shouldn't affect the ABI. 

Eh… the simplest case of a fancy pointer is a raw pointer to a class derived
from value_type. The allocator can provide an extra overload of deallocate to
help do the downcast. Such an allocator doesn’t even need to declare a fancy
pointer type, but it can. I don’t know how far that works currently, or if
you’re interested in supporting such hacks.

In any case, great! Sorry about the false alarms, I was only looking at the
online diff viewer :P .=
>From gcc-bugs-return-489258-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 17 22:29:57 2015
Return-Path: <gcc-bugs-return-489258-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 82537 invoked by alias); 17 Jun 2015 22:29:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 82516 invoked by uid 48); 17 Jun 2015 22:29:52 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally
Date: Wed, 17 Jun 2015 22:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57272-4-3BJzwqyYkN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57272-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57272-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01590.txt.bz2
Content-length: 2262

https://gcc.gnu.org/bugzilla/show_bug.cgi?idW272

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |potswa at mac dot com

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In PR55409#c15 David Krauss pointed out that ...

> the simplest case of a fancy pointer is a raw pointer to a class derived from value_type

I hadn't considered that case, and should ensure it works.

Currently I am working on something like this, which should handle it
correctly:

  template<typename _Traits,
           typename _Tp = typename _Traits::value_type,
           typename _Ptr = typename _Traits::pointer>
    struct _List_node_traits;

  // For C++03 allocators, and C++11 allocators without non-fancy pointers.
  template<typename _Traits, typename _Tp>
    struct _List_node_traits<_Traits, _Tp, _Tp*>
    {
      typedef _List_iterator<_Tp>       iterator;
      typedef _List_const_iterator<_Tp> const_iterator;
      typedef _List_node<_Tp>           _Node;
      typedef __detail::_List_node_base _Node_base;
      typedef _Node_base*               _Node_base_ptr;
      typedef const _Node_base*         _Node_base_const_ptr;
      typedef typename _Traits::template rebind<_Node>::other _Alloc_type;
      typedef __gnu_cxx::__alloc_traits<_Alloc_type> _Alloc_traits;
      ...
    };

#if __cplusplus >= 201103L
  // For C++11 allocators with fancy pointers.
  template<typename _Traits, typename _Tp, typename _Ptr>
    struct _List_node_traits
    {
      typedef typename _Traits::void_pointer    void_pointer;
      typedef _List_ptr_iterator<_Ptr>          iterator;
      typedef _List_ptr_const_iterator<_Ptr>    const_iterator;
      typedef _List_ptr_node<_Ptr>              _Node;
      typedef _List_ptr_node_base<void_pointer> _Node_base;
      typedef typename _Node_base::_SelfPtr     _Node_base_ptr;
      typedef typename _Node_base::_ConstSelfPtr        _Node_base_const_ptr;
      typedef typename _Traits::template rebind<_Node>::other _Alloc_type;
      typedef __gnu_cxx::__alloc_traits<_Alloc_type> _Alloc_traits;
      ...
    };
#endif


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits
  2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
                   ` (13 preceding siblings ...)
  2015-06-17 22:20 ` potswa at mac dot com
@ 2015-09-10 20:30 ` redi at gcc dot gnu.org
  14 siblings, 0 replies; 16+ messages in thread
From: redi at gcc dot gnu.org @ 2015-09-10 20:30 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for gcc-6 but I'm not planning to backport it to gcc-5.


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2015-09-10 20:30 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-20  8:51 [Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits benjamin.kircher at gmail dot com
2012-11-20  9:13 ` [Bug libstdc++/55409] " redi at gcc dot gnu.org
2012-11-20  9:25 ` redi at gcc dot gnu.org
2012-11-20  9:31 ` benjamin.kircher at gmail dot com
2012-11-20 10:30 ` redi at gcc dot gnu.org
2014-09-02 19:11 ` freddie_chopin at op dot pl
2014-09-03  4:27 ` redi at gcc dot gnu.org
2014-09-03  6:35 ` freddie_chopin at op dot pl
2014-09-03 11:20 ` redi at gcc dot gnu.org
2015-04-10 14:42 ` redi at gcc dot gnu.org
2015-04-10 14:42 ` redi at gcc dot gnu.org
2015-06-16 16:29 ` redi at gcc dot gnu.org
2015-06-17 20:37 ` redi at gcc dot gnu.org
2015-06-17 21:20 ` potswa at mac dot com
2015-06-17 22:20 ` potswa at mac dot com
2015-09-10 20:30 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).