Issue with GAWK compilation (how to get 64 bit integers)

This is the basic test program:

BEGIN {print lshift(1,55)	# Any number >32 and <64 is OK

Using the gawk that came with this Linux system (which claims to be 3.1.3),
the program generates the desired output (a large number).  Using the GAWK
that I compiled myself on the same system (version 3.1.4), it prints 0.
Why?

Notes:
1) The following short C program, compiled on the same system, with
no special options (in fact, "gcc x.c"), generates the desired
result:

main()
{
long long i;
i = 1ll << 55;
printf("sizeof(i) = %d, i = %lld\n",sizeof(i),i);
}

So, we know the compiler environment works.  But it looks like something in
the GAWK compilation caused it to go 32 bit.

2) My version of GAWK compiled on Solaris (*) also does 64 bit
correctly.

(*) In fact, this is on Solaris 5 (pretty old version) with a pretty old
version of gcc.

Kenny McCormack wrote:

> This is the basic test program:
>
>     BEGIN {print lshift(1,55)	# Any number >32 and <64 is OK
>
> Using the gawk that came with this Linux system (which claims to be 3.1.3)
,
> the program generates the desired output (a large number).  Using the GAWK
> that I compiled myself on the same system (version 3.1.4), it prints 0.
> Why?

I never knew that gawk on the 64 bit OSs used
64 bit integers. But I have a DEC Alpha machine
here with gawk 3.1.0 which really does this:

gawk 'BEGIN {print lshift(1,55)}'
36028797018963968
br2dec07:~(2)> uname -a
OSF1 br2dec07.hb.orthogon.com V5.1 732 alpha
br2dec07:~(3)> gawk --version
GNU Awk 3.1.0
Copyright (C) 1989, 1991-2001 Free Software Foundation.


> So, we know the compiler environment works.  But it looks like something i
n
> the GAWK compilation caused it to go 32 bit.

I guess it is this change which causes the different behavior:

2003-03-26  Paul Eggert  <eggert@twinsun.com>

* builtin.c [HAVE_INTTYPES_H]: Include <inttypes.h>.
[!HAVE_INTTYPES_H && HAVE_STDINT_H]: Include <stdint.h>.
(CHAR_BIT, INTMAX_MIN, UINTMAX_MAX): Define if the system does not.
(TYPE_SIGNED, TYPE_MINIMUM, TYPE_MAXIMUM): New macros, taken from
coreutils and many other GNU utilities.
(format_tree): When formatting, use widest possible integers
rather than settling with 'long'.
(do_lshift, do_rshift, do_and, do_or, do_xor, do_compl): Likewise,
when doing bitwise operations.

In article <3bupveF6l8k44U1@individual.net>,
examnotes  <Juergen.KahrsDELETETHIS@vr-web.de> wrote:
>Kenny McCormack wrote:
> 
>
>I never knew that gawk on the 64 bit OSs used
>64 bit integers. But I have a DEC Alpha machine
>here with gawk 3.1.0 which really does this:
>
>gawk 'BEGIN {print lshift(1,55)}'
>36028797018963968
>br2dec07:~(2)> uname -a
>OSF1 br2dec07.hb.orthogon.com V5.1 732 alpha
>br2dec07:~(3)> gawk --version
>GNU Awk 3.1.0
>Copyright (C) 1989, 1991-2001 Free Software Foundation.

But note that the real point is that it should work on any platform that
supports 64 bit "long long"s, which isn't limited to 64 bit hardware.  My
testing has been on "generic" Intel (32 bit) and on 32 bit Sparc hardware.

As I understand it, the "long long" type is emulated in software.
 
>
>I guess it is this change which causes the different behavior:
>
>2003-03-26  Paul Eggert  <eggert@twinsun.com>
>
>	* builtin.c [HAVE_INTTYPES_H]: Include <inttypes.h>.
>	[!HAVE_INTTYPES_H && HAVE_STDINT_H]: Include <stdint.h>.
>	(CHAR_BIT, INTMAX_MIN, UINTMAX_MAX): Define if the system does not.
>	(TYPE_SIGNED, TYPE_MINIMUM, TYPE_MAXIMUM): New macros, taken from
>	coreutils and many other GNU utilities.
>	(format_tree): When formatting, use widest possible integers
>	rather than settling with 'long'.
>	(do_lshift, do_rshift, do_and, do_or, do_xor, do_compl): Likewise,
>	when doing bitwise operations.

Right - in fact, I've located the code in builtin.c:

uval = (uintmax_t) val;
ushift = (uintmax_t) shift;

res = uval << ushift;
return tmp_integer(res);

So I assume uintmax_t is supposed to be "long long".

Anyway, the question is: Why does the version that I compiled only use 32
bit here, while the system compiled version has 64 bit.  I don't think
I did anything different or strange in the build process.

Kenny McCormack wrote:

> But note that the real point is that it should work on any platform that
> supports 64 bit "long long"s, which isn't limited to 64 bit hardware.  My
> testing has been on "generic" Intel (32 bit) and on 32 bit Sparc hardware.

Yes, that's true. I also understood uintmax_t
as the largest supported integer type.

> Anyway, the question is: Why does the version that I compiled only use 32
> bit here, while the system compiled version has 64 bit.  I don't think
> I did anything different or strange in the build process.

It looks like uintmax_t is a rather new type.
It did not exist in the 1997 Posix stanard,
but in later ones since 1999. So I guess your
problem comes from an unfortunate combination
of C library and configuration.