(Still) ICE for cris-elf at r214710

Hans-Peter Nilsson hans-peter.nilsson@axis.com
Fri Aug 29 04:14:00 GMT 2014


Sorry for the context-less mail but I didn't find a proper
obvious gcc-patches-message to reply to.  (Also, I can't log
into bugzilla because to enter a PR as there appears to have
been some SSL changes such that my old firefox and gcc.gnu.org
can no longer agree on a cipher or something.)  But, since
r214690 and at up to and including r214714 (HEAD as of this
writing), a build for cris-elf fails on trunk 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=v8 -mbest-lib-options -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -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 -DUSE_EMUTLS -o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c /tmp/hpautotest-gcc1/gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
/tmp/hpautotest-gcc1/gcc/libgcc/libgcc2.c: In function '__lshrdi3':
/tmp/hpautotest-gcc1/gcc/libgcc/libgcc2.c:426:1: internal compiler error: in safe_as_a, at is-a.h:205
 }
 ^
0x9119c2 safe_as_a<rtx_insn*, rtx_def>
        /tmp/hpautotest-gcc1/gcc/gcc/is-a.h:205
0x9119c2 JUMP_LABEL_AS_INSN
        /tmp/hpautotest-gcc1/gcc/gcc/rtl.h:1663
0x9119c2 find_dead_or_set_registers
        /tmp/hpautotest-gcc1/gcc/gcc/resource.c:500
0x912408 mark_target_live_regs(rtx_insn*, rtx_insn*, resources*)
        /tmp/hpautotest-gcc1/gcc/gcc/resource.c:1115
0x90cb4b fill_slots_from_thread
        /tmp/hpautotest-gcc1/gcc/gcc/reorg.c:2404
0x90ff45 fill_eager_delay_slots
        /tmp/hpautotest-gcc1/gcc/gcc/reorg.c:2933
0x90ff45 dbr_schedule
        /tmp/hpautotest-gcc1/gcc/gcc/reorg.c:3742
0x9108ef rest_of_handle_delay_slots
        /tmp/hpautotest-gcc1/gcc/gcc/reorg.c:3885
0x9108ef execute
        /tmp/hpautotest-gcc1/gcc/gcc/reorg.c:3916
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_lshrdi3.o] Error 1

Use "./cc1 -fpreprocessed this.i -O2" to repeat.

struct DWstruct {int low, high;};

typedef union
{
  struct DWstruct s;
  long long ll;
} DWunion;

long long
__lshrdi3 (long long u, int b)
{
  if (b == 0)
    return u;

  const DWunion uu = {.ll = u};
  const int bm = (4 * (8)) - b;
  DWunion w;

  if (bm <= 0)
    {
      w.s.high = 0;
      w.s.low = (unsigned int) uu.s.high >> -bm;
    }
  else
    {
      const unsigned int carries = (unsigned int) uu.s.high << bm;

      w.s.high = (unsigned int) uu.s.high >> b;
      w.s.low = ((unsigned int) uu.s.low >> b) | carries;
    }

  return w.ll;
}

That aside, I must say, I'm somewhat impressed by the work
you've done here, and the fears I expressed at the Cauldron
about churn to port-specific code (i.e. supposedly making
back-porting bug-fixes to older releases difficult) seem to
thankfully have been unfounded in the patches I've seen.
(IIRC, I saw *one* type-change; one line, for two ports!)

Also, I wouldn't worry too much trying to go to great lengths to
try and *avoid* this kind of fallout (it's just going to happen,
QED), as long as you're prepared to handle it quickly.  And
thanks in advance for that! ;)

brgds, H-P



More information about the Gcc-patches mailing list