stupid pointer alignment question (re: cernlib on m68k)

["Kevin B. McCarty" <kmccarty@Princeton.EDU>]

Hi,
I am wondering: will g77 et al. cause programs to automatically align all
32-bit integers in memory with pointers that are multiples of 4 bytes?  
(Given that the integers are array elements that aren't members of any
other structure, and exist at compile time.)  Because I'm seeing a bug in
pawX11.static (in cernlib's paw-static package) on m68k that appears to
result from a violation of that assumption.

Here's a sample gdb session on powerpc, where it works correctly (I have
omitted gdb output until the important point)

arcturus[33]:~/Debian/cernlib/paw-test% gdb pawX11.static
(gdb) b hlimit_
(gdb) r
(gdb) b mzbook_
(gdb) c
(gdb) b mzlift.F:340
(gdb) c
Breakpoint 3, mzlift_ (ixdiv=0x10579768, lp=0x10d6e3f8, lsupp=0x10d6e3e8, 
    jbias=0x10487bec, name=0x10e64eec, nzero=0x1046e92c)
    at /home/kmccarty/Debian/cernlib/cernlib-2003.09.03/src/packlib/zebra/mq/mzlift.F:340
340           LQ(KQS+KADR)   = NQLS
(gdb) p *LSUPP
$1 = (0, 0, 0, 0, 0, 0, 0, 0, 0)
(gdb) n
342        79 LP(1) = NQLS
(gdb) p *LSUPP
$2 = (1999569, 0, 0, 0, 0, 0, 0, 0, 0)
(gdb) p LSUPP
$3 = (PTR TO -> ( integer (9))) 0x10d6e3e8
(gdb) p & LQ(KQS+KADR)
$4 = (PTR TO -> ( integer )) 0x10d6e3e8

Second, the same session repeated on m68k:

kullervo[13]:~/chroot-build/cernlib-2003.09.03/bin$ gdb ./pawX11.static
[identical operations as above snipped]
340           LQ(KQS+KADR)   = NQLS
(gdb) p *LSUPP
$1 = (0, 0, 0, 0, 0, 0, 0, 0, 0)
(gdb) n
342        79 LP(1) = NQLS
(gdb) p *LSUPP
$2 = (30, -2100232192, 0, 0, 0, 0, 0, 0, 0)
(gdb) p LSUPP
$3 = (PTR TO -> ( integer (9))) 0x80c30c78
(gdb) p & LQ(KQS+KADR)
$4 = (PTR TO -> ( integer )) 0x80c30c7a

Note that LQ(KQS+KADR) is now offset from LSUPP by 2 bytes even though 
both are declared as arrays of (4-byte) integers!  So is this a bug in 
g77 / as / ld on m68k, or is the cernlib code just doing something 
unreliable?

Another oddity, by the way, is that the above problem only exists on m68k
when the cernlib libraries are statically linked into the pawX11
executable; when they are separate dynamic libraries, it does not occur 
(although other problems appear later).

thanks,

-- 
Kevin B. McCarty <kmccarty@princeton.edu>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/    Princeton University
GPG: public key ID 4F83C751                 Princeton, NJ 08544