Fix problem with guality tests

Fix problem with guality tests

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

-----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-----

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 1032 bytes --]

	* gcc-gdb-test.exp (gdb-test): Reorder matchers to give more
	consistent results.

Index: gcc-gdb-test.exp
===================================================================
*** gcc-gdb-test.exp	(revision 171108)
--- gcc-gdb-test.exp	(working copy)
*************** proc gdb-test { args } {
*** 60,65 ****
--- 60,71 ----
      }
  
      remote_expect target [timeout_value] {
+ 	# Too old GDB
+ 	-re "Unhandled dwarf expression|Error in sourced command file" {
+ 	    unsupported "$testname"
+ 	    remote_close target
+ 	    return
+ 	}
  	-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)
*************** proc gdb-test { args } {
*** 72,83 ****
  	    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
--- 78,83 ----

Re: Fix problem with guality tests

[Mike Stump]

On Mar 17, 2011, at 1:33 PM, Jeff Law wrote:
> The guality tests can randomly fail due to expect buffering issues.

> OK for trunk?

Generally, I really would prefer the people that create and maintain an area to review and approve these sorts of changes...  The narrower the reviewer, the better.  Failing that...

Ok.