From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27687 invoked by alias); 31 May 2012 10:05:39 -0000 Received: (qmail 27675 invoked by uid 22791); 31 May 2012 10:05:38 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 31 May 2012 10:05:15 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4VA4qFN009265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 May 2012 06:04:52 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4VA4n1W028263; Thu, 31 May 2012 06:04:49 -0400 Message-ID: <4FC74240.2070706@redhat.com> Date: Thu, 31 May 2012 10:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jan Kratochvil CC: Jeff Kenton , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [patch] Compilation regression on older gcc + 32-bit host [Re: [PATCH] Add support for Tilera TILE-Gx processor (part 1/3: gdb)] References: <4FAD39A1.1000209@tilera.com> <20120514162046.GI10253@adacore.com> <4FBA4FD2.9090108@tilera.com> <4FBD1F67.9090609@redhat.com> <4FBE8B5E.6050800@tilera.com> <4FBFA26F.20002@redhat.com> <4FC4EA20.1040201@tilera.com> <4FC67B1C.6040700@redhat.com> <20120531085250.GA31740@host2.jankratochvil.net> In-Reply-To: <20120531085250.GA31740@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg01078.txt.bz2 On 05/31/2012 09:52 AM, Jan Kratochvil wrote: > On CentOS i386 (gcc-4.4.6-3.el6.i686): > > tilegx-linux-tdep.c:59: error: integer constant is too large for ‘long’ type > tilegx-linux-tdep.c:60: error: integer constant is too large for ‘long’ type > > I would put there ULL for ULONGEST although there was recent discusssion 'long > long' is not acceptable. But sourceware tree already has large number of > 'long long' uses: > $ egrep -ri '[0-9] *U?LL\>' .|egrep -v '/(opcodes|libdecnumber)/'|wc -l > 303 Not quite. bfd's only use of "long long" in common code is guarded by HAVE_STRTOULL. I can't find any unconditional long long use in the whole of binutils. opcodes uses long long in many ports, but then there are many ports that don't use it. It's native toolchains on those ports that could be problematic (old hosts with old, non-gcc compilers). (People on such hosts wouldn't be using "--enable-targets=all", nor building cross toolchains). You're right about libdecnumber. It takes care to not assume stdint.h is available, etc., but then uses long long / ull unconditionally. If I'm reading the code correctly, any project that depends on libdecnumber is therefore already depending on long long unconditionally too. In any case, for gdb, I think it's now safe to assume that long long is available on all supported hosts. > So I find 'long long' is perfectly valid for Sourceware tree. > > Still the "right" fix would be below. > > I will check it in with ULL today if no comments appear. LONGEST (the type of the field the constant in question is initializing) is defined like so: #ifdef BFD64 #define LONGEST BFD_HOST_64_BIT #define ULONGEST BFD_HOST_U_64_BIT #else /* No BFD64 */ #ifdef CC_HAS_LONG_LONG #define LONGEST long long #define ULONGEST unsigned long long #else #ifdef BFD_HOST_64_BIT /* BFD_HOST_64_BIT is defined for some hosts that don't have long long (e.g. i386-windows) so try it. */ #define LONGEST BFD_HOST_64_BIT #define ULONGEST BFD_HOST_U_64_BIT #else #define LONGEST long #define ULONGEST unsigned long #endif #endif and this means we're assuming the "#define LONGEST long" is never reached nowaways, or that if it does, long is 64-bit. That'd be fine with me. It'd be super fine with the below as well, and it might even be better (stop the non-fixed-sized types insanity). You should then change tramp_frame to use uint64_t instead of ULONGEST, though. > gdb/ > 2012-05-31 Jan Kratochvil > > * tilegx-linux-tdep.c (tilegx_l): Use UINT64_C. > > --- ./gdb/tilegx-linux-tdep.c 30 May 2012 19:31:44 -0000 1.1 > +++ ./gdb/tilegx-linux-tdep.c 31 May 2012 08:43:23 -0000 > @@ -56,8 +56,8 @@ static const struct tramp_frame tilegx_l > SIGTRAMP_FRAME, > 8, > { > - { 0x00045fe551483000, -1 }, /* { moveli r10, 139 } */ > - { 0x286b180051485000, -1 }, /* { swint1 } */ > + { UINT64_C (0x00045fe551483000), -1 }, /* { moveli r10, 139 } */ > + { UINT64_C (0x286b180051485000), -1 }, /* { swint1 } */ > { TRAMP_SENTINEL_INSN, -1 } > }, > tilegx_linux_sigframe_init -- Pedro Alves