From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Jeff Kenton <jkenton@tilera.com>,
Joel Brobecker <brobecker@adacore.com>,
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)]
Date: Thu, 31 May 2012 10:05:00 -0000 [thread overview]
Message-ID: <4FC74240.2070706@redhat.com> (raw)
In-Reply-To: <20120531085250.GA31740@host2.jankratochvil.net>
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 <jan.kratochvil@redhat.com>
>
> * 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
next prev parent reply other threads:[~2012-05-31 10:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 16:09 [PATCH] Add support for Tilera TILE-Gx processor (part 1/3: gdb) Jeff Kenton
2012-05-14 16:21 ` Joel Brobecker
2012-05-21 14:23 ` Jeff Kenton
2012-05-23 17:34 ` Pedro Alves
2012-05-24 19:26 ` Jeff Kenton
2012-05-25 15:17 ` Pedro Alves
2012-05-29 15:24 ` Jeff Kenton
2012-05-29 17:11 ` Jeff Kenton
2012-05-29 15:24 ` Jeff Kenton
2012-05-30 19:56 ` Pedro Alves
2012-05-30 20:09 ` Jeff Kenton
2012-05-31 8:53 ` [patch] Compilation regression on older gcc + 32-bit host [Re: [PATCH] Add support for Tilera TILE-Gx processor (part 1/3: gdb)] Jan Kratochvil
2012-05-31 10:05 ` Pedro Alves [this message]
2012-05-31 15:40 ` [patch] Require long long for GDB [Re: [patch] Compilation regression on older gcc + 32-bit host] Jan Kratochvil
2012-06-01 14:45 ` [commit] Fix tilegx-linux-tdep.c compilation [Re: [patch] Require long long for GDB] Jan Kratochvil
2012-05-14 16:24 ` [PATCH] Add support for Tilera TILE-Gx processor (part 1/3: gdb) Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC74240.2070706@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=jkenton@tilera.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox