../../../gcc/f/target.c:217: failed assertion `alignment > 0'

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

The current CVS source fails many g77 tests in the testsuite under hpux9.01
because of the following error:

spawn /xxx/gnu/egcs-2.93.10/objdir/gcc/g77 -B/xxx/gnu/egcs-2.93.10/objdir/gcc/ /
xxx/gnu/egcs-2.93.10/gcc/testsuite/g77.f-torture/compile/980310-2.f -w -O0 -L/xx
x/gnu/egcs-2.93.10/objdir/hppa1.1-hp-hpux9.01/libf2c -c -o /xxx/gnu/egcs-2.93.10
/objdir/gcc/testsuite/980310-2.o ^M
../../../gcc/f/target.c:217: failed assertion `alignment > 0'^M
g77: Internal compiler error: program f771 got fatal signal 6^M
compiler exited with status 1
output is:
../../../gcc/f/target.c:217: failed assertion `alignment > 0'^M
g77: Internal compiler error: program f771 got fatal signal 6^M

FAIL: g77.f-torture/compile/980310-2.f,  -O0

Here is some debugging info about the cause of the problem:
# gdb ../f771
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa1.1-hp-hpux9.01"...
(gdb) break target.c:217
Breakpoint 1 at 0xdde3c: file ../../../gcc/f/target.c, line 217.
(gdb) run -O1 -w 980310-2.f
Starting program: /xxx/gnu/egcs-2.93.10/objdir/gcc/testsuite/../f771 -O1 -w -c 9
80310-2.f
warning: Unable to find _DLD_HOOK symbol in object file.
warning: Suggest linking with /usr/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload calls

Breakpoint 1, ffetarget_align (updated_alignment=0x40052258 "\001",
    updated_modulo=0x40052259 "", offset=0, alignment=4, modulo=0)
    at ../../../gcc/f/target.c:217
217       assert (alignment > 0);
(gdb) print alignment
$1 = 0 '\000'
(gdb) info address alignment
Symbol "alignment" is a variable in register r10.
(gdb) info reg
   flags: 29000001       r18: 40052258     pcsqt:     3d65       ccr:        0
      r1: 40002f80       r19:        0      eiem: fffffffe      cr12:        0
      rp:    d363f       r20:        0       iir:    10004      cr13:        0
      r3: 7b0348b0       r21:        0       isr:     3d65      cr24:        0
      r4: 40052258       r22:        4       ior:        0      cr25:        0
      r5:       80       r23:        0      ipsw:    4000f      cr26: ffffffff
      r6: 40052218       r24:        0      goto:        2  mpsfu_hi:        0
      r7: 40052259       r25: 40052259       sr4:     3d65  mpsfu_lo:        0
      r8:        0       r26: 40052258       sr0:     3d65  mpsfu_ov:        0
      r9:        0        dp: 40014f80       sr1:     7543       pad:        0
     r10:        0      ret0: 4003faf8       sr2:        0      fpsr:        0
     r11: 7b0347c0      ret1:        1       sr3:        0      fpe1:        0
     r12:    1c800        sp: 7b034930       sr5:     7543      fpe2:        0
     r13: 40026f80       r31: 7af4603c       sr6:     7ae4      fpe3:        0
     r14:    1c800       sar:       10       sr7:        0      fpe4:        0
     r15:    1c800     pcoqh:    dde3c       cr0:        0      fpe5:        0
     r16:    1c800     pcsqh:     3d65       cr8:        0      fpe6:        0
     r17:        0     pcoqt:    dde40       cr9:        0      fpe7:        0

As can be seen, ffetarget_align is called with alignment=4.  However,
when the procedure is started, alignment has the value 0 and as a
consequence the assertion of line 217 of target.c fails the test
"alignment > 0".

(gdb) disass
Dump of assembler code for function ffetarget_align:
0xddde0 <ffetarget_align>:      stw rp,-14(sr0,sp)
0xddde4 <ffetarget_align+4>:    stwm r18,80(sr0,sp)
0xddde8 <ffetarget_align+8>:    copy r26,r18
0xdddec <ffetarget_align+12>:   stw r10,-60(sr0,sp)
0xdddf0 <ffetarget_align+16>:   stw r17,-7c(sr0,sp)
0xdddf4 <ffetarget_align+20>:   ldi 0,r17
0xdddf8 <ffetarget_align+24>:   stw r15,-74(sr0,sp)
0xdddfc <ffetarget_align+28>:   stw r9,-5c(sr0,sp)
0xdde00 <ffetarget_align+32>:   stw r8,-58(sr0,sp)
0xdde04 <ffetarget_align+36>:   copy r23,r8
0xdde08 <ffetarget_align+40>:   copy r24,r9
0xdde0c <ffetarget_align+44>:   ldb -b4(sr0,sp),r10
0xdde10 <ffetarget_align+48>:   stw r16,-78(sr0,sp)
0xdde14 <ffetarget_align+52>:   stw r14,-70(sr0,sp)
0xdde18 <ffetarget_align+56>:   stw r13,-6c(sr0,sp)
0xdde1c <ffetarget_align+60>:   stw r12,-68(sr0,sp)
0xdde20 <ffetarget_align+64>:   stw r11,-64(sr0,sp)
0xdde24 <ffetarget_align+68>:   stw r7,-54(sr0,sp)
0xdde28 <ffetarget_align+72>:   stw r6,-50(sr0,sp)
0xdde2c <ffetarget_align+76>:   stw r5,-4c(sr0,sp)
0xdde30 <ffetarget_align+80>:   stw r4,-48(sr0,sp)
0xdde34 <ffetarget_align+84>:   stw r3,-44(sr0,sp)
0xdde38 <ffetarget_align+88>:   stw r25,-a8(sr0,sp)
0xdde3c <ffetarget_align+92>:   comibf,= 0,r10,0xdde64 <ffetarget_align+132>

It looks like r10 is clobbered at 

0xdde0c <ffetarget_align+44>:   ldb -b4(sr0,sp),r10

The compiler bootstrap was done with CFLAGS="-g -O3".

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)