c++/8779: C++ allocator calls using stl map class bug?

c++/8779: C++ allocator calls using stl map class bug?

[marc_bumble]

>Number:         8779
>Category:       c++
>Synopsis:       C++ allocator calls using stl map class bug?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 01 19:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Marc Bumble
>Release:        gcc version 3.2
>Organization:
>Environment:
/usr/local/build/usr/bin/gcc  --version
gcc (GCC) 3.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 /usr/local/build/usr/bin/gcc -v
Reading specs from /usr/local/build/usr/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/usr --enable-shared --enable-languages=java,c,c++,f77,objc --enable-threads=posix --with-slibdir=/lib --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.2

uname -a
Linux cadence.glidepath.org 2.4.18 #8 SMP Tue Jul 9 23:27:08 EDT 2002 i686 unknown

mkdir ../gcc-build &&
 cd ../gcc-build &&
 ../gcc-3.2/configure --prefix=/usr --enable-shared \
     --enable-languages=java,c,c++,f77,objc --enable-threads=posix \
     --with-slibdir=/lib --enable-__cxa_atexit \
     --enable-clocale=gnu &&
 make bootstrap &&
 make install &&
 ln -s ../usr/bin/cpp /lib &&
 ln -s ../bin/cpp /usr/lib &&
 ln -s gcc /usr/bin/cc
>Description:
I am not fully sure that there is a compiler issue, but
the error looks suspicious.  I am writing a C++ allocator.
When I attempt to compile an STL map<> class with it, I
get an error message which itself looks like it has a
mistake.  

I have not yet worked out a small test case, as the entire
allocator probably needs to be provided, but the allocator
interface was working fine with gcc 3.0.4.

Let me know if you need a sample test case, and I will do my
best to provide one.  The coding issue  which causes the 
problem appears as:

    typedef std::map<std::string, Container*,
		     std::less<std::string>,
		     Pool_alloc<std::pair<std::string, Container*>,
				alloc_type,
				memory_segment_key> > map_t;
    // Pointer to the Container map index
    map_t* map_p;

The compiler error messages are:

/usr/local/build/usr/include/c++/3.2/bits/stl_tree.h:531: no matching function 
   for call to `allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const 
   std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
   main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>::Pool_alloc(const 
   allocator_ns::Pool_alloc<std::pair<const std::basic_string<char, 
   std::char_traits<char>, std::allocator<char> >, main(int, 
   char**)::x_vector_t*>, sharedpooled, (&temp)>&)'
../include/allocator.h:281: candidates are: 
   allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const 
   std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
   main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>::Pool_alloc(const 
   allocator_ns::Pool_alloc<std::_Rb_tree_node<std::pair<const 
   std::basic_string<char, std::char_traits<char>, std::allocator<char> >, 
   main(int, char**)::x_vector_t*> >, sharedpooled, (&temp)>&)
../include/allocator.h:359:                 allocator_ns::Pool_alloc<T, 
   alloc_type, alloc_key>::Pool_alloc() [with T = 
   std::_Rb_tree_node<std::pair<const std::basic_string<char, 
   std::char_traits<char>, std::allocator<char> >, main(int, 
   char**)::x_vector_t*> >, mem_space::AllocatorType alloc_type = sharedpooled, 
   const char*alloc_key = (&temp)]


I am not sure why the candidate has the std::_Rb_tree_node<std::pair<const ..
part which looks like an error?  I think it should just be
std::pair<const without the _Rb_tree_node part.

Seems like a mistake to me.  Or I am way off and just
missing something obvious?  Please let me know.  I will
do my best to provide a sucint example if it is required.
The size of the allocator code is a little large though, and
I am not sure how to make it succint.

Thanks you for any assistance with this error,

marc

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c++/8779: C++ allocator calls using stl map class bug?

[bangerth]

Synopsis: C++ allocator calls using stl map class bug?

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Mon Dec  2 12:50:45 2002
State-Changed-Why:
    Submitter error.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8779

Re: c++/8779: C++ allocator calls using stl map class bug?

[Marc D Bumble]

The following reply was made to PR c++/8779; it has been noted by GNATS.

From: Marc D Bumble <marc_bumble@uml.edu>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, marc_bumble@cpinternet.com
Cc:  
Subject: Re: c++/8779: C++ allocator calls using stl map class bug?
Date: Mon, 2 Dec 2002 14:45:53 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8779
 
 Hi,
 
 I found the issue.  It was my coding oversight, or so I believe at the
 moment.  I would like to withdraw  the bug report if that is possible.
 The bug was in my allocator definition, not the compiler.
 
 Apologies for the submission,
 
 
 Thanks,
 
 Marc
 
 Number: 8779
 Category: c++
 Synopsis: C++ allocator calls using stl map class bug?
 Confidential: no
 Severity: serious
 Priority: medium
 Responsible: unassigned
 State: open
 Class: sw-bug
 Submitter-Id: net
 Arrival-Date: Sun Dec 01 19:06:00 PST 2002
 Closed-Date:
 Last-Modified:
 Originator: Marc Bumble
 Release:
 
 
 
 
 
 >> "gcc-gnats" == gcc-gnats  <gcc-gnats@gcc.gnu.org> writes:
 
   > Thank you very much for your problem report.  It has the internal
   > identification `c++/8779'.  The individual assigned to look at
   > your report is: unassigned.
 
   >> Category: c++ Responsible: unassigned Synopsis: C++ allocator
   >> calls using stl map class bug?  Arrival-Date: Sun Dec 01 19:06:00
   >> PST 2002