From patchwork Sat Jul 26 05:57:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 2183 Received: (qmail 14537 invoked by alias); 26 Jul 2014 05:57:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 14518 invoked by uid 89); 26 Jul 2014 05:57:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f48.google.com X-Received: by 10.70.65.40 with SMTP id u8mr15272902pds.96.1406354245540; Fri, 25 Jul 2014 22:57:25 -0700 (PDT) From: Alan Modra To: bug-gnulib@gnu.org, libc-alpha@sourceware.org Cc: Alan Modra Subject: [PATCH 0/5] obstacks Date: Sat, 26 Jul 2014 15:27:07 +0930 Message-Id: <1406354233-7664-1-git-send-email-amodra@gmail.com> This patch series gives obstacks some much needed TLC. The first patch is mostly just a tidy, with one perhaps controversial change, renaming the function obstack_free to _obstack_free. This will be visible to users who compile some code using a new obstack.h and try to link against an old (but not ancient!) relocatable obstack.o. They will need to recompile their obstack.o. Users linking against glibc won't see a problem since glibc exports both _obstack_free and obstack_free. I figure the number of people affected by this rename is small, and note that gnulib made a change that would similarly affect linking against relocatable object files when _obstack_free was removed.. The second and third patch get us to the point where 4G obstacks are supported without significantly changing the ABI. At this point some code will need fixes, due to people wrongly using obstack internals. For instance, gcc needs some changes like the following (which is backward compatible with current libiberty obstacks): gcc needs other fixes for existing upstream obstack changes, obstack_base() now returns a void* where it previously returned a char*. The fourth patch switches obstacks to use size_t for sizes, and contains the necessary machinery for glibc to compile obstacks twice, once for version 1 compatibiliy, and once for version 2. The fifth patch avoids the necessity to install other gnulib headers in libiberty, and importantly, avoids the need for a whole lot of gnulib configury. Running configure already takes signigicant time in libiberty. I don't want to double that time. Alan Modra (5): obstack tidy 64-bit obstack support, part 1 64-bit obstack support, part 2 64-bit obstack support, part 3 obstack usability lib/obstack.c | 275 ++++++++++++++++++++++++------------------------------- lib/obstack.h | 244 ++++++++++++++++++++++++++++++------------------ modules/obstack | 1 + 3 files changed, 273 insertions(+), 247 deletions(-) Index: gcc/coretypes.h =================================================================== --- gcc/coretypes.h (revision 212477) +++ gcc/coretypes.h (working copy) @@ -158,13 +158,13 @@ struct basic_block_def; typedef struct basic_block_def *basic_block; typedef const struct basic_block_def *const_basic_block; -#define obstack_chunk_alloc ((void *(*) (long)) xmalloc) -#define obstack_chunk_free ((void (*) (void *)) free) +#define obstack_chunk_alloc xmalloc +#define obstack_chunk_free free #define OBSTACK_CHUNK_SIZE 0 -#define gcc_obstack_init(OBSTACK) \ - _obstack_begin ((OBSTACK), OBSTACK_CHUNK_SIZE, 0, \ - obstack_chunk_alloc, \ - obstack_chunk_free) +#define gcc_obstack_init(OBSTACK) \ + obstack_specify_allocation ((OBSTACK), OBSTACK_CHUNK_SIZE, 0, \ + obstack_chunk_alloc, \ + obstack_chunk_free) /* enum reg_class is target specific, so it should not appear in target-independent code or interfaces, like the target hook declarations