libstdc++/3904: STL does not use ::operator new as required in standard

libstdc++/3904: STL does not use ::operator new as required in standard

[matti.rintala]

>Number:         3904
>Category:       libstdc++
>Synopsis:       STL does not use ::operator new as required in standard
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 31 12:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Matti Rintala
>Release:        3.0
>Organization:
>Environment:
System: Linux mustikkakukko.cs.tut.fi 2.4.5 #1 Tue May 29 19:53:48 EEST 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.0/configure --host=athlon-pc-linux-gnu --prefix=/usr/local/gcc-3.0 --enable-shared --enable-threads --with-cpu=athlon --enable-cpp
>Description:
	ISO C++ standard states that by default STL containers use
	std::allocator to obtain memory. std::allocator in turn is required to
	use ::operator new and ::operator delete. However, STL in GCC
	specifically detects the use of std::allocator and uses malloc() in
	this case (this behaviour comes from the SGI STL code base). This
	breaks programs which override the default ::operator new and
	::operator delete.

	I understand the need for customised dynamic memory handling
	(which its own free memory lists etc) in STL,
	because it increases performance. However, even these kinds of
	optimisations should use ::operator new instead of malloc() so that
	they don't break the standard.
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: libstdc++/3904: STL does not use ::operator new as required in standard

[ljrittle]

Synopsis: STL does not use ::operator new as required in standard

State-Changed-From-To: open->closed
State-Changed-By: ljrittle
State-Changed-When: Tue Aug  7 10:58:06 2001
State-Changed-Why:
    Closed after off-mailing list discussion with Matti.
    Benjamin already fixed this on mainline.  Due to ABI
    concerns(?), it may not be moved to 3.0.X branch.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3904&database=gcc