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
Created attachment 15506 [details] compile with cc1 -fpreprocessed dp-bit.i -O2 Preprocessed dp-bit.c
Subject: Bug 36003 Author: zadeck Date: Tue Apr 22 13:43:47 2008 New Revision: 134559 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134559 Log: 2008-04-22 Kenneth Zadeck <zadeck@naturalbridge.com> PR middle-end/36003 * passes.c (init_optimization_passes): Remove pass_fast_rtl_byte_dce. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c
Confirmed.
Confirmed at r134530 with the following reduced test case: typedef unsigned int USItype __attribute__ ((mode (SI))); typedef unsigned int UDItype __attribute__ ((mode (DI))); typedef USItype halffractype; typedef UDItype fractype; typedef struct { unsigned int sign; int normal_exp; union { fractype ll; halffractype l[2]; } fraction; } fp_number_type; extern void bar (); extern fp_number_type * _fpmul_parts (fractype, fractype, fp_number_type *); fp_number_type * _fpmul_parts (fractype low, fractype high, fp_number_type *tmp) { while (high >= ((fractype) 1 << (52 + 1 + 8L))) { tmp->normal_exp++; if (high & 1) bar (); high >>= 1; } while (high < ((fractype) 1 << (52 + 8L))) { tmp->normal_exp--; high <<= 1; } tmp->fraction.ll = high; return tmp; } Unfortunately I can't reproduce it with the top-of-trunk of today.
The zero_extract:DI appears for the first time in the .163r.combine dump.
Why, actually, was the solution here to disable byte level DCE for all targets, when only CC0 targets are affected? Is there any reason why the pass cannot be enabled for non-CC0 machines?
rtl_byte_dce is gone. It was rewritten as run_word_dce called from lower-subreg, as part of the (apparently partial) fix for PR42575.