Re: Internal compiler error: program cc1 got fatal signal 4 building egcs-1.1a for vax-dec-ultrix4.3 - Possible fix: BUG RESURFACES WITH gcc-2.96

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

The following bug squashed previously has arisen again with gcc-2.96:

...
./xgcc -B/usr/local/vax-dec-ultrix4.3/bin/ -B./ -isystem /usr/local/vax-dec-ultr
ix4.3/include -S tmp-dum.c
xgcc: Internal compiler error: program cc1 got fatal signal 4

% gdb -c core cc1
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 "vax-dec-ultrix4.3"...
Core was generated by `cc1'.
#0  0x18e02 in fixup_unsigned_type (type=0x1b7f00)
    at ../../gcc/stor-layout.c:1680
1680      TYPE_MAX_VALUE (type)
Breakpoint 1 at 0x168115
Breakpoint 2 at 0x75eb2: file ../../gcc/rtl.c, line 1261.
Breakpoint 3 at 0x169a0a
(gdb) bt
#0  0x18e02 in fixup_unsigned_type (type=0x1b7f00)
    at ../../gcc/stor-layout.c:1680
#1  0x18950 in make_unsigned_type (precision=128)
    at ../../gcc/stor-layout.c:1519
#2  0x14197 in build_common_tree_nodes (signed_char=1) at ../../gcc/tree.c:5720
#3  0x14ca84 in init_decl_processing () at ../../gcc/c-decl.c:2904
#4  0x7444 in compile_file (name=0x7fffb772 "/usr/tmp/cczw4SiH.i")
    at ../../gcc/toplev.c:2064
#5  0xafd5 in main (argc=7, argv=0x7fffb580, 2147464608)
    at ../../gcc/toplev.c:4631

Note failure is with precision 128.

The failure occurs at

0x18e02 <fixup_unsigned_type+60>:       extzv r0,r2,r1,r0

(gdb) info reg
r0             0xffffffc0       -64
r1             0xffffffff       -1
r2             0x60     96

This is an illegal instruction.

Dave
> 
> 
>   In message <199809211517.LAA01410@hiauly1.hia.nrc.ca>you write:
>   > Dear Jeff:
>   > 
>   > Information about the underlying problem was previously submitted.  Sorry
>   > about the poor linkage. Here is the previous message:
> Thanks.
> 
>   > (gdb) bt
>   > #0  0x3a52e in fixup_unsigned_type (type=0x111468)
>   >     at ../../gcc/stor-layout.c:1248
>   > #1  0x3a31b in make_unsigned_type (precision=128)
>   >     at ../../gcc/stor-layout.c:1148
>   > #2  0xfdb3 in init_decl_processing () at ../../gcc/c-decl.c:3056
>   > #3  0x29dd6 in compile_file (name=0x7fffc0da "SYSCALLS.i")
>   >     at ../../gcc/toplev.c:2552
>   > #4  0x2fd93 in main (argc=13, argv=0x7fffc008, envp=0x7fffc040)
>   >     at ../../gcc/toplev.c:4838
>   > (gdb) info reg
>   > r0             0xffffffc0       -64
>   > r1             0xffffffff       -1
>   > r2             0x111460 1119328
>   > r3             0x1114c8 1119432
>   > r4             0x0      0
>   > r5             0x80     128
>   > r6             0x80     128
>   > r7             0x35b14  219924
>   > r8             0xf77f0  1013744
>   > r9             0x3a234  238132
>   > r10            0x3a2ee  238318
>   > r11            0xf77ec  1013740
>   > ap             0x7fffbf00       2147467008
>   > fp             0x7fffbee8       2147466984
>   > sp             0x7fffbee8       2147466984
>   > pc             0x3a52e  238894
>   > ps             0x3c00001        62914561
>   > (gdb) print precision
> I think the real problem here is you shouldn't have gotten a 128bit type when
> HOST_WIDE_INT is only 32 bits.
> 
> I think I know what the problem is.  I'll take care of it.
> 
> jeff
> 


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