This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Compilation regression on older gcc + 32-bit host [Re: [PATCH] Add support for Tilera TILE-Gx processor (part 1/3: gdb)]
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