Build worked with revision 134517. Build was broken with 134530 on, as
follows:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include -g -O2 -march=v10
-mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc
-I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/../include -DHAVE_CC_TLS -o _mul_df.o -MT
_mul_df.o -MD -MP -MF _mul_df.dep -DFINE_GRAINED_LIBRARIES -DL_mul_df -c
../../.././gcc/dp-bit.c
In file included from ../../.././gcc/dp-bit.c:46:
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:391: warning: 'packed'
attribute ignored for field of type 'fractype'
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:392: warning: 'packed'
attribute ignored for field of type 'unsigned int'
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/config/fp-bit.h:393: warning: 'packed'
attribute ignored for field of type 'unsigned int'
../../.././gcc/dp-bit.c:144: warning: conflicting types for built-in function
'nan'
../../.././gcc/dp-bit.c: In function '__muldf3':
../../.././gcc/dp-bit.c:965: internal compiler error: in
df_compute_accessed_bytes_extract, at df-byte-scan.c:79
(gdb) p m1_size
$1 = 8
The breaking insn is:
(insn:QI 214 213 215 25 ../../.././gcc/dp-bit.c:902 (set (cc0)
(zero_extract:DI (subreg:SI (reg/v:DI 38 [ high ]) 0)
(const_int 1 [0x1])
(const_int 0 [0x0]))) 16 {*btst} (nil))
for some reason, the zero_extract has gained DImode, while the subreg is in
SImode.
It has been argued that cris.md is wrong for having no mode for the
zero_extract:
(define_insn "*btst"
[(set (cc0)
(zero_extract
(match_operand:SI 0 "nonmemory_operand" "r,r,r,r,r,r,n")
(match_operand:SI 1 "const_int_operand" "K,n,K,n,K,n,n")
(match_operand:SI 2 "nonmemory_operand" "M,M,K,n,r,r,r")))]
...
but there's nothing inherently wrong in that:
"If @var{loc} is in a register, the mode to use is specified by the
operand of the @code{insv} or @code{extv} pattern
(@pxref{Standard Names}) and is usually a full-word integer mode,
which is the default if none is specified." says rtl.texi about sign_extract,
to which the zero_extract doc refers, making the modelessness a special-case.
This is the canonical btst pattern, see the m68k port. Compares don't have a
mode either, for cc0 ports, though test insns (compare to 0) do. Admittedly,
the cc0 ports are a mixed bunch, some specifying a mode for the zero_extract
expressions.
This /might/ be fixable by change the documentation (and all backends) to
require an explicit mode for all zero_extract/sign_extract expressions, but I'm
not sure. It's probably just a bug: there should never have been any DImode
operand generated in the first place, or perhaps some bug added it to the
zero_extract expression.
I haven't checked how this insn looked with 134517.
I'll attach dp-bit.i
--
Summary: df-byte-scan.c changes broke cris-elf compiling libgcc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
