From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 366583857C59 for ; Wed, 24 Nov 2021 13:25:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 366583857C59 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-552-q3GOkWwYN1SFGJWt7RG8Hw-1; Wed, 24 Nov 2021 08:25:31 -0500 X-MC-Unique: q3GOkWwYN1SFGJWt7RG8Hw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9D33210144E9; Wed, 24 Nov 2021 13:25:30 +0000 (UTC) Received: from localhost (unknown [10.33.36.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D2D3794A7; Wed, 24 Nov 2021 13:25:30 +0000 (UTC) From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [PATCH] libstdc++: Remove broken std::allocator base classes [PR103340] Date: Wed, 24 Nov 2021 13:25:29 +0000 Message-Id: <20211124132529.1196939-1-jwakely@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-14.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 13:25:35 -0000 I plan to commit this Real Soon. Please yell if you need these alternative std::allocator back-ends to stay (and explain how you're using them when they've been broken for years, and start sending test results to the gcc-testresults mailing list, and ideally offer to maintain them). Tested powerpc64le-linux. === 8< === 8< === 8< === The bitmap_allocator, __mt_alloc and __pool_alloc extensions are no longer suitable for use as the base class of std::allocator, because they have not been updated to meet the C++20 requirements. There is a patch attached to PR 103340 which addresses that, but more work would be needed to solve the linking errors that occur when the library is configured to use them. Using --enable-libstdcxx-allocator=bitmap wouldn't even bootstrap for the past few years, and I can't find any gcc-testresults reports using any of these allocators. This patch removes the configure option to use these are the std::allocator base class. The allocators are still in the tree and can be used directly, you just can't configure the library to use one of them as the base class of std::allocator. libstdc++-v3/ChangeLog: PR libstdc++/103340 PR libstdc++/103400 PR libstdc++/103381 * acinclude.m4 (GLIBCXX_ENABLE_ALLOCATOR): Remove mt, bitmap and pool options. * configure: Regenerate. * doc/xml/manual/allocator.xml: Update. * doc/xml/manual/configure.xml: Update. * doc/xml/manual/evolution.xml: Document removal. * doc/xml/manual/mt_allocator.xml: Editorial tweaks. * doc/html/manual/*: Regenerate. --- libstdc++-v3/acinclude.m4 | 14 +--- libstdc++-v3/configure | 14 +--- libstdc++-v3/doc/html/manual/api.html | 3 + libstdc++-v3/doc/html/manual/configure.html | 10 ++- libstdc++-v3/doc/html/manual/memory.html | 57 +++++----------- .../doc/html/manual/mt_allocator.html | 8 +-- libstdc++-v3/doc/xml/manual/allocator.xml | 67 ++++++------------- libstdc++-v3/doc/xml/manual/configure.xml | 10 ++- libstdc++-v3/doc/xml/manual/evolution.xml | 5 ++ libstdc++-v3/doc/xml/manual/mt_allocator.xml | 8 +-- 10 files changed, 64 insertions(+), 132 deletions(-) diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index 71321055de7..6d9a8875e31 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -2599,7 +2599,7 @@ AC_DEFUN([GLIBCXX_ENABLE_ALLOCATOR], [ AC_MSG_CHECKING([for std::allocator base class]) GLIBCXX_ENABLE(libstdcxx-allocator,auto,[[[=KIND]]], [use KIND for target std::allocator base], - [permit new|malloc|mt|bitmap|pool|yes|no|auto]) + [permit new|malloc|yes|no|auto]) # If they didn't use this option switch, or if they specified --enable # with no specific model, we'll have to look for one. If they @@ -2631,26 +2631,14 @@ AC_DEFUN([GLIBCXX_ENABLE_ALLOCATOR], [ # Set configure bits for specified locale package case ${enable_libstdcxx_allocator_flag} in - bitmap) - ALLOCATOR_H=config/allocator/bitmap_allocator_base.h - ALLOCATOR_NAME=__gnu_cxx::bitmap_allocator - ;; malloc) ALLOCATOR_H=config/allocator/malloc_allocator_base.h ALLOCATOR_NAME=__gnu_cxx::malloc_allocator ;; - mt) - ALLOCATOR_H=config/allocator/mt_allocator_base.h - ALLOCATOR_NAME=__gnu_cxx::__mt_alloc - ;; new) ALLOCATOR_H=config/allocator/new_allocator_base.h ALLOCATOR_NAME=__gnu_cxx::new_allocator ;; - pool) - ALLOCATOR_H=config/allocator/pool_allocator_base.h - ALLOCATOR_NAME=__gnu_cxx::__pool_alloc - ;; esac GLIBCXX_CONDITIONAL(ENABLE_ALLOCATOR_NEW, diff --git a/libstdc++-v3/doc/xml/manual/allocator.xml b/libstdc++-v3/doc/xml/manual/allocator.xml index 1f429410eb0..aaab4e29aa7 100644 --- a/libstdc++-v3/doc/xml/manual/allocator.xml +++ b/libstdc++-v3/doc/xml/manual/allocator.xml @@ -154,8 +154,9 @@ - The base class that allocator is derived from - may not be user-configurable. + The choice of base class that allocator + is derived from is fixed at the time when GCC is built, + and the different choices are not ABI compatible. @@ -314,6 +315,13 @@ new_allocator. + + Since C++11 the minimal interface require for an allocator is + much smaller, as std::allocator_traits + can provide default for much of the interface. + + +
Extension Allocators @@ -359,9 +367,10 @@ debug_allocator - A wrapper around an arbitrary allocator A. It passes on - slightly increased size requests to A, and uses the extra - memory to store size information. When a pointer is passed + A wrapper around an arbitrary allocator A. + It passes on slightly increased size requests to A, + and uses the extra memory to store size information. + When a pointer is passed to deallocate(), the stored size is checked, and assert() is used to guarantee they match. @@ -393,52 +402,16 @@ - Older versions of this class take a boolean template - parameter, called thr, and an integer template - parameter, called inst. + For thread-enabled configurations, the pool is locked with a + single big lock. In some situations, this implementation detail + may result in severe performance degradation. - The inst number is used to track additional memory - pools. The point of the number is to allow multiple - instantiations of the classes without changing the semantics at - all. All three of + (Note that the GCC thread abstraction layer allows us to provide + safe zero-overhead stubs for the threading routines, if threads + were disabled at configuration time.) - - - typedef __pool_alloc<true,0> normal; - typedef __pool_alloc<true,1> private; - typedef __pool_alloc<true,42> also_private; - - - behave exactly the same way. However, the memory pool for each type - (and remember that different instantiations result in different types) - remains separate. - - - The library uses 0 in all its instantiations. If you - wish to keep separate free lists for a particular purpose, use a - different number. - - The thr boolean determines whether the - pool should be manipulated atomically or not. When - thr = true, the allocator - is thread-safe, while thr = - false, is slightly faster but unsafe for - multiple threads. - - - - For thread-enabled configurations, the pool is locked with a - single big lock. In some situations, this implementation detail - may result in severe performance degradation. - - - - (Note that the GCC thread abstraction layer allows us to provide - safe zero-overhead stubs for the threading routines, if threads - were disabled at configuration time.) - diff --git a/libstdc++-v3/doc/xml/manual/configure.xml b/libstdc++-v3/doc/xml/manual/configure.xml index cc9c8554c6c..8c26acc95a7 100644 --- a/libstdc++-v3/doc/xml/manual/configure.xml +++ b/libstdc++-v3/doc/xml/manual/configure.xml @@ -118,12 +118,10 @@ --enable-libstdcxx-allocator=OPTION Select a target-specific underlying std::allocator. The - choices are 'new' to specify a wrapper for new, 'malloc' to - specify a wrapper for malloc, 'mt' for a fixed power of two allocator, - 'pool' for the SGI pooled allocator or 'bitmap' for a bitmap allocator. - See this page for more information on allocator - extensions. This option - can change the library ABI. + choices are 'new' to specify a wrapper for new, and 'malloc' to + specify a wrapper for malloc. + See for more information. + This option can change the library ABI. diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml index 9aef84a0933..271d2225c3a 100644 --- a/libstdc++-v3/doc/xml/manual/evolution.xml +++ b/libstdc++-v3/doc/xml/manual/evolution.xml @@ -1033,6 +1033,11 @@ accessors for the unexpected handler are deprecated for C++11 and later. Dynamic exception specifications should be replaced with noexcept. + +The bitmap, mt, and pool +options for were removed. + +
diff --git a/libstdc++-v3/doc/xml/manual/mt_allocator.xml b/libstdc++-v3/doc/xml/manual/mt_allocator.xml index 93504a7d711..f1c09b3bd8f 100644 --- a/libstdc++-v3/doc/xml/manual/mt_allocator.xml +++ b/libstdc++-v3/doc/xml/manual/mt_allocator.xml @@ -20,12 +20,12 @@ The mt allocator [hereinafter referred to simply as "the allocator"] is a fixed size (power of two) allocator that was initially - developed specifically to suit the needs of multi threaded + developed specifically to suit the needs of multi-threaded applications [hereinafter referred to as an MT application]. Over time the allocator has evolved and been improved in many ways, in - particular it now also does a good job in single threaded - applications [hereinafter referred to as a ST application]. (Note: - In this document, when referring to single threaded applications + particular it now also does a good job in single-threaded + applications [hereinafter referred to as an ST application]. (Note: + In this document, when referring to single-threaded applications this also includes applications that are compiled with gcc without thread support enabled. This is accomplished using ifdef's on __GTHREADS). This allocator is tunable, very flexible, and capable -- 2.31.1