sh-coff build error with gcc-3.5-20040704

[Jim Wilson]

Nitin Shah wrote:
> gcc   -O2 -DCOFFPATCH -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes  -fno-common   -DHAVE_CONFIG_H    -I. -I. -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/. -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/../include -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/../libcpp/include -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/../libbanshee/libcompat -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/../libbanshee -I/home/kpit/fsfsrc/downloads/gcc-3.5-20040704/gcc/../libbanshee/points-to  -c insn-emit.c \
>   -o insn-emit.o
> insn-emit.c:8249: Internal compiler error in simplify_subreg, at simplify-rtx.c:2452

Sending mail to gcc-bugs isn't very useful, as we don't track bug 
reports mailed to the lists.  If you have a bug that you want someone 
else to fix, you are better off filing a bug report into bugzilla.  If 
you want help fixing it yourself, then the gcc list is OK.

This isn't a bug in gcc mainline.  This is a bug in the gcc on the host 
system, e.g. /usr/bin/gcc.  You didn't mention the host, but this is 
probably not our problem.  You could try getting an update from the 
system vendor, or you could try building your own gcc for the host and 
installing it somewhere like /usr/local/bin to use for gcc builds.

I have seen similar problems on an RHL 8 machine.  The sh.md file 
contains patterns for 64-bit instructions that only get emitted when 
configured for sh5.  The patterns contain assumptions that HOST_WIDE_INT 
is 64-bits, which is true if you have configured for a 64-bit target. 
However, the patterns always get emitted to the insn-emit.c file, even 
when you configure for a 32-bit target.  If you are building on a 32-bit 
host, then HOST_WIDE_INT is 32-bits, and you get all kinds of warnings 
for code that does shifts greater than 32-bits on HOST_WIDE_INT, which 
happens to be invalid code in this case.  This should be harmless, as 
the invalid code will never be executed.  However, the RHL8 compiler 
gets confused while compiling the invalid code, and ends up hitting an 
abort.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com