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
