32-bit: int, long and pointer to 32 bits. Short is 16 bits
64-bit: int to 32 bits and long and pointer to 64 bits.

 --------------------------------------------------------------
 This revealed two minor bugs:
In system.c, the
ret = sbrk( 4 - (int)sbrk(0) % 4 );
has a pointer cast to int, which makes the compiler complain.
Also, the prototype for times(), given as
extern int times P(( struct tms * ));
should have been
extern clock_t times P(( struct tms * ));
according to POSIX.

So, it was very easy to make it compile. Unfortunately,
GAP crashes on everything I do. Looking at the sources,
these are filled with (undocumented?) assumptions about
the underlying hardware.

I get

gap> 2^59+2^59;
0

because integer.c tests for overflow (e.g. in SumInt) by

    i = (long)hdL + (long)hdR - 1;

    if ( ((i << 1) >> 1) == i )
        return (TypHandle)i;

but longs have 64 bits, so 2^59 is still stored as a small integer.
However, when the sum does not fit in a small integer, GAP does

    i = HD_TO_INT(hdL) + HD_TO_INT(hdR);
    if ( 0 < i ) {
        hdS = NewBag( T_INTPOS, 4*sizeof(TypDigit) );
        ((TypDigit*)PTR(hdS))[0] = i;
        ((TypDigit*)PTR(hdS))[1] = i >> 16;
    }

preserving only 32 bits.
Also Gasman fails in various ways, like in:

gap> Bell(34);
Gasman: last bag of type +12 and size    16 has overwritten the free bag.

I have not really traced this bug, but again there are all kinds
of hidden assumptions (like in

    HdFree->size -= (size + SIZE_HD + SIZE_HD-1) & ~(SIZE_HD-1);

which will only work when SIZE_HD is a power of two).

Since I hear people talking about GAP on the Alpha, perhaps
someone debugged all this already?
This gap3r4p3 is more than a year old. Is there a more recent version?

Best regards,
Andries Brouwer 
