Fix problem with guality tests

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The guality tests can randomly fail due to expect buffering issues.

Given this output:

Breakpoint 1 at 0x4004d6: file
/home/gcc/virgin-gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 18.^M
^M
Breakpoint 1, foo (k=7, l=Unhandled dwarf expression opcode 0xf3^M
) at /home/gcc/virgin-gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:22^M
22        asm volatile ("" : : "r" (k), "r" (l));^M
$1 = 8^M
$2 = 8^M


And this matcher:



    remote_expect target [timeout_value] {
        -re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
            set first $expect_out(1,string)
            set second $expect_out(2,string)
            if { $first == $second } {
                pass "$testname"
            } else {
                send_log "$first != $second\n"
                fail "$testname"
            }
            remote_close target
            return
        }
        # Too old GDB
        -re "Unhandled dwarf expression|Error in sourced command file" {
            unsupported "$testname"
            remote_close target
            return
        }
        timeout {
            unsupported "$testname"
            remote_close target
            return
        }
    }


The first thing to realize is that output can match two cases.  One
where we actually have a pass/fail for the test or the second case where
we have too old GDB.   When more than one case matches, the first has
priority (ie, the pass/fail case).

Furthermore, depending on buffering issues, we may or may not see the $1
= 8 and $2 = 8 lines at the right time and thus we'd fall match the "too
old gdb" case.

This results in the exact same test sometime passing/failing and other
times being unsupported which makes comparing test runs difficult.

This patch reorders the two clauses so that in the case of a double
match, we'll be consistent with the case where matching occurs before
seeing the $1 = and $2 = lines.  Hopefully this brings some more
stability to the guality tests.

OK for trunk?

Jeff



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNgnA0AAoJEBRtltQi2kC7RzcIAL1zWdJcXKah8Jz7xhcpu/cb
xlraZl5rdvfBTrLGvseznrLWS71xPOpskFAGAgNYv3OD/8W1AlNNbV2qLNx1LQRL
p3/0X7rkfhNZq1CIixz5CRAim7ryP66W3haLhW5bZ0sfIwrAiFUy+gnyTuiCnO4R
xkWoowIezScKKPX7rTm7OQRX+qf6yNnFl8jqcu1agiwpeL8dk2S4D2T3Q/RhMmBs
m0Ekj9CCl9UJARxv6i0N5+5meoMx6oRg/dzod/XgDYQOQIOhVjukgTGX/I3GZYLZ
Bfie/1RknC86/dQUsVHqAS4Vv0mecGjlgmRyY8kh2Uz9eTZR5pPG2n4NTJJHR9A=
=G1b6
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: P
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110317/171447c7/attachment.ksh>