Please fix regressions from your sim changes

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

My autotester screams.  Please fix cris-elf and mips-elf.

For mips-elf, there's just
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/mips/basic.exp ...
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)
FAIL: mips1 hilo-hazard-1.s (execution)

>From sim.log it seems just some expected patterns need updating.

Executing on host: mips-elf-ld hilo-hazard-1.s.o -N -Ttext=0x80010000   -o hilo-hazard-1.s.x    (timeout = 300)
/tmp/hpautotest-sim/mips-elf/sim/mips/run     hilo-hazard-1.s.x 
HILO: MULT: OP at 0x80010048 too close to MF at 0x80010044

output:  HILO: MULT: OP at 0x80010048 too close to MF at 0x80010044


pattern: HILO: * too close to MF at *\
\
program stopped*\

FAIL: mips1 hilo-hazard-1.s (execution)


For cris-elf, there's quite a bit more, three variants AFAICT;
three "signals" lost.

Test Run By hp on Mon Mar 19 05:31:34 2012
Target is cris-axis-elf
Host   is x86_64-unknown-linux-gnu

		=== sim tests ===

Schedule of variations:
    cris-sim

Running target cris-sim
Using ~/dejagnuboards/cris-sim.exp as board description file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for target.
Using /tmp/hpautotest-sim/src/sim/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/arm/allinsn.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/arm/iwmmxt/iwmmxt.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/arm/misc.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/arm/thumb/allthumb.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/arm/xscale/xscale.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/bfin/allinsn.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/cr16/allinsn.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/cr16/misc.exp ...
Running /tmp/hpautotest-sim/src/sim/testsuite/sim/cris/asm/asm.exp ...
FAIL: crisv10 addqpc.ms (execution)
FAIL: crisv10 movecpc.ms (execution)
FAIL: crisv10 movempc.ms (execution)
FAIL: crisv10 movepcb.ms (execution)
FAIL: crisv10 movepcd.ms (execution)
FAIL: crisv10 movepcw.ms (execution)
FAIL: crisv10 moveqpc.ms (execution)
FAIL: crisv10 moverbpc.ms (execution)
FAIL: crisv10 moverdpc.ms (execution)
FAIL: crisv10 moverpcb.ms (execution)
FAIL: crisv10 moverpcw.ms (execution)
FAIL: crisv10 moverwpc.ms (execution)
FAIL: crisv10 movppc.ms (execution)
FAIL: crisv10 movscpc.ms (execution)
FAIL: crisv10 movsmpc.ms (execution)
FAIL: crisv10 movsrpc.ms (execution)
FAIL: crisv10 movucpc.ms (execution)
FAIL: crisv10 movumpc.ms (execution)
FAIL: crisv10 movurpc.ms (execution)
FAIL: crisv10 msteppc1.ms (execution)
FAIL: crisv10 msteppc2.ms (execution)
FAIL: crisv10 msteppc3.ms (execution)
FAIL: crisv10 sbfs.ms (execution)
FAIL: crisv10 subqpc.ms (execution)
FAIL: crisv32 boundmv32.ms (execution)
FAIL: crisv32 fidxd.ms (execution)
FAIL: crisv32 fidxi.ms (execution)
FAIL: crisv32 ftagd.ms (execution)
FAIL: crisv32 ftagi.ms (execution)
FAIL: crisv32 halt.ms (execution)
FAIL: crisv32 io6.ms (execution)
FAIL: crisv32 io7.ms (execution)
FAIL: crisv32 io8.ms (execution)
FAIL: crisv32 io9.ms (execution)
FAIL: crisv32 movrss.ms (execution)
FAIL: crisv32 movssr.ms (execution)
FAIL: crisv32 rfg.ms (execution)

In the sim.log, I see:
Executing on host: cris-elf-ld addqpc.ms.o     -o addqpc.ms.x    (timeout = 300)
/tmp/hpautotest-sim/cris-elf/sim/cris/run     addqpc.ms.x 
General register read of PC is not implemented.
output:  General register read of PC is not implemented.

pattern: General register read of PC is not implemented.
program stopped with signal 5.

FAIL: crisv10 addqpc.ms (execution)

Most failures are similar.  As the CRIS simulator just calls
cgen_rtx_error for these errors there's no need to provide a
specific faked signal number, but at least the test-suite needs
adjusting.  Still, see below.

Similarly the lost "SIGSEGV" messages:

Executing on host: cris-elf-as /tmp/hpautotest-sim/src/sim/testsuite/sim/cris/asm/io9.ms  -I/tmp/hpautotest-sim/src/sim/
testsuite/sim/cris/asm  --march=v32 -o io9.ms.o    (timeout = 300)
Executing on host: cris-elf-ld io9.ms.o --section-start=.text=0    -o io9.ms.x    (timeout = 300)
/tmp/hpautotest-sim/cris-elf/sim/cris/run     io9.ms.x 
ce11d0c
core: 4 byte write to unmapped address 0x90000004 at 0x16
output:  ce11d0c
core: 4 byte write to unmapped address 0x90000004 at 0x16

pattern: ce11d0c
core: 4 byte write to unmapped address 0x90000004 at 0x16
program stopped with signal 11.

FAIL: crisv32 io9.ms (execution)

I require not more than a test-suite tweak for these too.

For a few tests, matters are worse:
Executing on host: cris-elf-as /tmp/hpautotest-sim/src/sim/testsuite/sim/cris/asm/boundmv32.ms  -I/tmp/hpautotest-sim/sr
c/sim/testsuite/sim/cris/asm  --march=v32 -o boundmv32.ms.o    (timeout = 300)
Executing on host: cris-elf-ld boundmv32.ms.o     -o boundmv32.ms.x    (timeout = 300)
/tmp/hpautotest-sim/cris-elf/sim/cris/run     boundmv32.ms.x 
output:  
pattern: program stopped with signal 4.

FAIL: crisv32 boundmv32.ms (execution)

There, missing indication of cause.  Signal 4 is "always"
SIGILL, so the cause used to be unambiguous; now it just looks
like abort is called.  *Some* kind of indication that the CGEN
framework executed an illegal instruction is needed; it doesn't
have to be "signal 4".  The output needs to be fixed adding an
indication.

And really, why removing the "program stopped with signal"
common part?  I see no reason to not just adding it back.

Also, be more careful when testing your changes.

brgds, H-P