From patchwork Thu Apr 5 15:00:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tristan Gingold X-Patchwork-Id: 150971 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id CF4BFB6FD9 for ; Fri, 6 Apr 2012 01:00:54 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1334242855; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date: Cc:Content-Transfer-Encoding:Message-Id:References:To: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=WSOeKsscnTMpdiGHHJDk YszBOJE=; b=E8rQOenETHf8dl0/TEh1pyS8ENeSiuBPnVkdFVjWyhurobBTSBk1 u7OmlJjYT5JLszySRwTnr9nzP+tWwakFdOJV/nwwr0SLs2j3eQ/pzzTTCDpJ+FhT QGvW48DLuBu43Y3tpPCyZ9yGQ1YPVTipABm0kfTKP4SyvW/OMJ/k3iI= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=JM8gvDtpVfZL+wG1Fg9NsqY6IBLtQKwPqDG/eFDX+TBwHFa1ID7Lm3USp0R013 j0oOOm4gzJObyCyAwDnWXamIDzGgqhLh4CDmjX+IssdpaA9Py27HLFoSPZjn9+0B pIUcjLHo9p6FFE0cs9OESrKSq3DsH4xgBk3gE5E935pNo=; Received: (qmail 23221 invoked by alias); 5 Apr 2012 15:00:48 -0000 Received: (qmail 23207 invoked by uid 22791); 5 Apr 2012 15:00:46 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL, BAYES_00, KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 15:00:21 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 087C2290064; Thu, 5 Apr 2012 17:00:25 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wucniIIELsdB; Thu, 5 Apr 2012 17:00:24 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id E9A30290009; Thu, 5 Apr 2012 17:00:24 +0200 (CEST) Subject: [Libiberty - V2]: Handle VMS as a LLP64 platform in splay-tree.h Mime-Version: 1.0 (Apple Message framework v1257) From: Tristan Gingold In-Reply-To: Date: Thu, 5 Apr 2012 17:00:19 +0200 Cc: GCC Patches Message-Id: <3D7B738C-1084-471F-99FD-18D2C0A8F7E9@adacore.com> References: <991EB52A-1080-4EED-8D17-2E73BF8050A0@adacore.com> To: Ian Lance Taylor X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote: > Tristan Gingold writes: > >> Would something like that be acceptable ? >> I have just checked that I can still build gcc with that patch. If you like this approach I will properly submit a patch. > > Thanks. > > You should also test that gdb continues to build with this patch. > > I guess the question here is portability. Do we still care about > portability to systems that have neither inttypes.h nor stdint.h? I'm > willing to try this and see if anybody complains. > > Ian Hi, here is my formal patch submission. I am not concerned by portability as configure will define uintptr_t if not found in inttypes.h or stdint.h (both in libiberty and gcc. gdb indeed uses stdint.h from gnulib). Tested by bootstrapping gcc for c,c++ and fortran on x86_64-darwin, and by building gdb on x86_64-darwin. Ok for trunk ? Tristan. gcc/ 2012-04-05 Tristan Gingold * gengtype.c (main): Make uintptr_t a known type. include/ 2012-04-05 Tristan Gingold * splay-tree.h: Conditionnaly includes stdint.h and inttypes.h (libi_uhostptr_t, libi_shostptr_t): Remove, replaced by uintptr_t. diff --git a/gcc/gengtype.c b/gcc/gengtype.c index 7450eeb..fa45392 100644 --- a/gcc/gengtype.c +++ b/gcc/gengtype.c @@ -4976,6 +4976,7 @@ main (int argc, char **argv) POS_HERE (do_scalar_typedef ("double_int", &pos)); POS_HERE (do_scalar_typedef ("uint64_t", &pos)); POS_HERE (do_scalar_typedef ("uint8", &pos)); + POS_HERE (do_scalar_typedef ("uintptr_t", &pos)); POS_HERE (do_scalar_typedef ("jword", &pos)); POS_HERE (do_scalar_typedef ("JCF_u2", &pos)); POS_HERE (do_scalar_typedef ("void", &pos)); diff --git a/include/splay-tree.h b/include/splay-tree.h index 480b2c4..a26135a 100644 --- a/include/splay-tree.h +++ b/include/splay-tree.h @@ -37,18 +37,11 @@ extern "C" { #include "ansidecl.h" -#ifndef _WIN64 - typedef unsigned long int libi_uhostptr_t; - typedef long int libi_shostptr_t; -#else -#ifdef __GNUC__ - __extension__ +#ifdef HAVE_STDINT_H +#include #endif - typedef unsigned long long libi_uhostptr_t; -#ifdef __GNUC__ - __extension__ -#endif - typedef long long libi_shostptr_t; +#ifdef HAVE_INTTYPES_H +#include #endif #ifndef GTY @@ -59,8 +52,8 @@ extern "C" { these types, if necessary. These types should be sufficiently wide that any pointer or scalar can be cast to these types, and then cast back, without loss of precision. */ -typedef libi_uhostptr_t splay_tree_key; -typedef libi_uhostptr_t splay_tree_value; +typedef uintptr_t splay_tree_key; +typedef uintptr_t splay_tree_value; /* Forward declaration for a node in the tree. */ typedef struct splay_tree_node_s *splay_tree_node;