From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6693 invoked by alias); 19 Mar 2012 06:29:21 -0000 Received: (qmail 6681 invoked by uid 22791); 19 Mar 2012 06:29:19 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ra.se.axis.com (HELO ra.se.axis.com) (195.60.68.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Mar 2012 06:28:53 +0000 Received: from localhost (localhost [127.0.0.1]) by ra.se.axis.com (Postfix) with ESMTP id 45080167316; Mon, 19 Mar 2012 07:28:52 +0100 (CET) Received: from ra.se.axis.com ([127.0.0.1]) by localhost (ra.se.axis.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bpfmjegEIRFf; Mon, 19 Mar 2012 07:28:50 +0100 (CET) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by ra.se.axis.com (Postfix) with ESMTP id 73ABF1672CB; Mon, 19 Mar 2012 07:28:50 +0100 (CET) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by thoth.se.axis.com (Postfix) with ESMTP id 71396340B3; Mon, 19 Mar 2012 07:28:50 +0100 (CET) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id q2J6SoF6011318; Mon, 19 Mar 2012 07:28:50 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id q2J6SnLJ011314; Mon, 19 Mar 2012 07:28:49 +0100 Date: Mon, 19 Mar 2012 06:29:00 -0000 Message-Id: <201203190628.q2J6SnLJ011314@ignucius.se.axis.com> From: Hans-Peter Nilsson To: vapier@gentoo.org CC: gdb-patches@sourceware.org Subject: Please fix regressions from your sim changes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00691.txt.bz2 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