[Bug middle-end/36003] New: df-byte-scan.c changes broke cris-elf compiling libgcc

[Bug middle-end/36003] New: df-byte-scan.c changes broke cris-elf compiling libgcc

[hp at gcc dot gnu dot org]

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

[Bug middle-end/36003] df-byte-scan.c changes broke cris-elf compiling libgcc

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2008-04-22 03:48 -------
Created an attachment (id=15506)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15506&action=view)
compile with cc1 -fpreprocessed dp-bit.i -O2

Preprocessed dp-bit.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003

[Bug middle-end/36003] [4.4 Regression] df-byte-scan.c changes broke cris-elf compiling libgcc

[zadeck at gcc dot gnu dot org]

------- Comment #2 from zadeck at gcc dot gnu dot org  2008-04-22 13:44 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in cris-elf and others targets

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-05 05:13 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|x86_64-unknown-linux-gnu    |
   Last reconfirmed|0000-00-00 00:00:00         |2008-05-05 05:13:12
               date|                            |
            Summary|[4.4 Regression] df-byte-   |pass_fast_rtl_byte_dce is
                   |scan.c changes broke cris-  |disabled currently because
                   |elf compiling libgcc        |of breakage in cris-elf and
                   |                            |others targets


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu dot org]

------- Comment #4 from steven at gcc dot gnu dot org  2009-01-02 18:21 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2009-01-02 18:25 -------
The zero_extract:DI appears for the first time in the .163r.combine dump.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu dot org]

------- Comment #6 from steven at gcc dot gnu dot org  2010-01-28 16:35 -------
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?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003