WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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
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
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:
#define LONGEST long long
#define ULONGEST unsigned long long
/* 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
#define LONGEST long
#define ULONGEST unsigned long
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.