Re: Miscellaneous testsuitsuite failures under hpux 10.20

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

> 1) Abort due to unexpected floating point signal.
> 
> gcc/ /xxx/gnu/gcc-2.96/gcc/testsuite/gcc.c-torture/compile/20000405-3.c  -w  -O0 -c  -threads -o /xxx/gnu/gcc-2.96/objdir/gcc/testsuite/20000405-3.o    (timeout = 300)
> /xxx/gnu/gcc-2.96/gcc/testsuite/gcc.c-torture/compile/20000405-3.c: In function `foo':^M
> /xxx/gnu/gcc-2.96/gcc/testsuite/gcc.c-torture/compile/20000405-3.c:7: Internal compiler error in `float_signal', at toplev.c:1542^M
> Please submit a full bug report.^M
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.^M
> compiler exited with status 1

The trap is due to a conditional trap in $$divU (divide by 0).  The divide
by 0 occurs at expmed.c:841.  Here is the backtrace for the above test:

#0  store_split_bit_field (op0=0x4006ebb0, bitsize=32, bitpos=0,
    value=0x4006ea80, align=0) at ../../gcc/expmed.c:841
#1  0xbfce8 in store_bit_field (str_rtx=0x3e, bitsize=32, bitnum=0,
    fieldmode=SImode, value=0x4006ea80, align=0, total_size=160)
    at ../../gcc/expmed.c:612
#2  0x9f7e8 in store_field (target=0x4006ebb0, bitsize=32, bitpos=0,
    mode=SImode, exp=0x40076180, value_mode=VOIDmode, unsignedp=1, align=0,
    total_size=160, alias_set=0) at ../../gcc/expr.c:4932
#3  0x9b3bc in expand_assignment (to=0x4005cda0, from=0x40076180,
    want_value=0, suggest_reg=1074195072) at ../../gcc/expr.c:3547
#4  0xaf4ac in expand_expr (exp=0x4005cdc0, target=0x0, tmode=VOIDmode,
    modifier=EXPAND_NORMAL) at ../../gcc/expr.c:8223
#5  0x86848 in expand_expr_stmt (exp=0x4005cdc0) at ../../gcc/stmt.c:1876
#6  0x25e8e8 in expand_stmt_with_iterators_1 (stmt=0x4005cdc0, iter_list=0x0)
    at ../../gcc/c-iterate.c:183
#7  0x25e668 in iterator_expand (stmt=0x4005cdc0) at ../../gcc/c-iterate.c:158
#8  0x228d44 in yyparse () at c-parse.y:2112
#9  0x39338 in compile_file (name=0x4006e7a0 "20000405-3.i")
    at ../../gcc/toplev.c:2289
#10 0x3e88c in main (argc=2, argv=0x7b03a774) at ../../gcc/toplev.c:4726
#11 0x7af1e6bc in ?? () from /usr/lib/libc.1

The problem is that store_split_bit_field is called with align=0, resulting
in unit=0.  So, how did align get to be 0?

The problem seems to be in the code generated for stor-layout.c line 862:

  DECL_OFFSET_ALIGN (field) = rli->offset_align;

On debugging, rli->offset_align has the value 256 in the first call to
place_field but the value is not being stored in field.

The assembly code for line 862 generated in the build at -O2 and -O3 is:

        .stabn 68,0,862,L$M286-place_field
L$M286:
	ldb 11(%r6),%r19

The tree checking stuff for the previous 2 lines and this one has been
combined.  Here, rli is in r3 and field is nominally in r6.

The assembly code generated at -O1 is:

        .stabn 68,0,862,L$M275-place_field
L$M275:
L$BB0123
	ldb 8(%r3),%r19
	ldi 36,%r25
	comb,= %r25,%r19,L$0303
	copy %r3,%r20
	ldil LR'L$C0019,%r19
	ldo RR'L$C0019(%r19),%r19
	stw %r19,-52(%r30)
	copy %r3,%r26
	ldil LR'L$C0000,%r24
	ldo RR'L$C0000(%r24),%r24
	.CALL ARGW0=GR,ARGW1=GR,ARGW2=GR,ARGW3=GR
	bl tree_check_failed,%r2
	ldi 862,%r23
L$0303
L$BE0123
	ldb 11(%r8),%r19
	stb %r19,39(%r20)

Here, I believe, rli is in r8 and field in r20.  So, why did the final
store get deleted at -O2 and -O3?

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

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