[PING][PATCH] gnu_vector.exp: Avoid some more known FAILs

[PING][PATCH] gnu_vector.exp: Avoid some more known FAILs

[Andreas Arnez]

Ping: https://sourceware.org/ml/gdb-patches/2015-07/msg00564.html

-- >8 --
Subject: [PATCH] gnu_vector.exp: Avoid some more known FAILs

This avoids two more types of FAILs with the gnu_vector test case.

First, for POWER targets newer GCCs emit an ABI note when invoked with
"-mcpu=native".  Then the test case fell back to non-native compile,
producing code for a non-vector ABI.  But that is not supported by GDB.
Thus the compiler note is now suppressed with "-Wno-psabi".

Second, on s390 the test case produced FAILs after falling back to a
non-vector ABI when using "finish" or "return" in a vector-valued
function.  This was due to a long-standing known bug (Bug 8549).  This
case is now detected, and KFAILs are emitted instead.

gdb/testsuite/ChangeLog:

	* gdb.base/gnu_vector.exp: Try compilation with "-mcpu=native
	-Wno-psabi" if "-mcpu=native" fails.  For the tests with "finish"
	and "return" use KFAIL when GDB can not read/write the vector
	return value.
---
 gdb/testsuite/gdb.base/gnu_vector.exp | 57 +++++++++++++++++++++++++++--------
 1 file changed, 44 insertions(+), 13 deletions(-)

diff --git a/gdb/testsuite/gdb.base/gnu_vector.exp b/gdb/testsuite/gdb.base/gnu_vector.exp
index 173da4d..0bef3f8 100644
--- a/gdb/testsuite/gdb.base/gnu_vector.exp
+++ b/gdb/testsuite/gdb.base/gnu_vector.exp
@@ -25,11 +25,19 @@ standard_testfile .c
 # without a CPU option.  If all variants fail, assume that the
 # compiler can not handle GNU vectors.
 
-if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" ${binfile} executable {debug quiet additional_flags=-mcpu=native}] != ""
-     && [gdb_compile "${srcdir}/${subdir}/${srcfile}" ${binfile} executable {debug quiet additional_flags=-march=native}] != ""
-     && [gdb_compile "${srcdir}/${subdir}/${srcfile}" ${binfile} executable {debug quiet}] != ""} {
-    untested "compiler can't handle the vector_size attribute?"
-    return -1
+proc do_compile { {opts {}} } {
+    global srcdir subdir srcfile binfile
+    set ccopts {debug quiet}
+    foreach opt $opts {lappend ccopts "additional_flags=$opt"}
+    gdb_compile "${srcdir}/${subdir}/${srcfile}" "$binfile" executable $ccopts
+}
+
+if { [do_compile {-mcpu=native}] != ""
+     && [do_compile {-mcpu=native -Wno-psabi}] != ""
+     && [do_compile {-march=native}] != ""
+     && [do_compile] != ""} {
+	untested "compiler can't handle vector_size attribute?"
+	return -1
 }
 
 clean_restart ${binfile}
@@ -195,14 +203,37 @@ gdb_test "print add_structvecs(i2, (struct just_int2)\{2*i2\}, (struct two_int2)
 gdb_test "print add_singlevecs((char1) \{6\}, (int1) \{12\}, (double1) \{24\})" "= \\{42\\}" \
     "call add_singlevecs"
 
-# Test vector return value handling with "finish" and "return".
+# Test "finish" from vector-valued function.
 gdb_breakpoint "add_some_intvecs"
 gdb_continue "add_some_intvecs"
-gdb_test "finish" "Value returned is .* = \\{10, 20, 48, 72\\}" \
-    "finish shows vector return value"
+set test "finish shows vector return value"
+gdb_test_multiple "finish" $test {
+    -re "Value returned is .* = \\{10, 20, 48, 72\\}.*$gdb_prompt $" {
+	pass $test
+    }
+    -re "Value returned has type: .* Cannot determine contents.*$gdb_prompt $" {
+	kfail "gdb/8549" $test
+    }
+}
+
+# Test "return" from vector-valued function.
 gdb_continue "add_some_intvecs"
-gdb_test "return (int4) \{4, 2, 7, 6\}" \
-    "#0 .* main .*" \
-    "set vector return value" \
-    "Make add_some_intvecs return now. .y or n.*" "y"
-gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
+set test "set vector return value"
+set ok 1
+gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
+    -re "#0 .* main .*$gdb_prompt $" {
+	if { $ok } {
+	    pass $test
+	    gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
+	}
+    }
+    -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
+	kfail "gdb/8549" $test
+	set ok 0
+	exp_continue
+    }
+    -re "Make add_some_intvecs return now. .y or n. $" {
+	send_gdb "y\n"
+	exp_continue
+    }
+}
-- 
2.5.0

Re: [PING][PATCH] gnu_vector.exp: Avoid some more known FAILs

[Pedro Alves]

On 08/11/2015 06:27 PM, Andreas Arnez wrote:
> +gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
> +    -re "#0 .* main .*$gdb_prompt $" {
> +	if { $ok } {
> +	    pass $test
> +	    gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
> +	}
> +    }
> +    -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
> +	kfail "gdb/8549" $test
> +	set ok 0
> +	exp_continue
> +    }
> +    -re "Make add_some_intvecs return now. .y or n. $" {
> +	send_gdb "y\n"
> +	exp_continue
> +    }
> +}

If this fails without matching the first pattern above, then we can
end up with a duplicate test message (kfail + fail).

Maybe do something like this instead:

set test "set vector return value"
set should_kfail 0
set finished 0
gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
    -re "#0 .* main .*$gdb_prompt $" {
        set finished 1
    }
    -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
	set should_kfail 1
	exp_continue
    }
    -re "Make add_some_intvecs return now. .y or n. $" {
	send_gdb "y\n"
	exp_continue
    }
}
if { $finished } {
    if { $should_kfail } {
        kfail "gdb/8549" $test
    } else {
	pass $test
        gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
    }
}

Otherwise LGTM.

Thanks,
Pedro Alves

Re: [PING][PATCH] gnu_vector.exp: Avoid some more known FAILs

[Andreas Arnez]

On Wed, Aug 12 2015, Pedro Alves wrote:

> On 08/11/2015 06:27 PM, Andreas Arnez wrote:
>> +gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
>> +    -re "#0 .* main .*$gdb_prompt $" {
>> +	if { $ok } {
>> +	    pass $test
>> +	    gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
>> +	}
>> +    }
>> +    -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
>> +	kfail "gdb/8549" $test
>> +	set ok 0
>> +	exp_continue
>> +    }
>> +    -re "Make add_some_intvecs return now. .y or n. $" {
>> +	send_gdb "y\n"
>> +	exp_continue
>> +    }
>> +}
>
> If this fails without matching the first pattern above, then we can
> end up with a duplicate test message (kfail + fail).

That's true.  Thanks for pointing out.

> Maybe do something like this instead:
>
> set test "set vector return value"
> set should_kfail 0
> set finished 0
> gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
>     -re "#0 .* main .*$gdb_prompt $" {
>         set finished 1
>     }
>     -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
> 	set should_kfail 1
> 	exp_continue
>     }
>     -re "Make add_some_intvecs return now. .y or n. $" {
> 	send_gdb "y\n"
> 	exp_continue
>     }
> }
> if { $finished } {
>     if { $should_kfail } {
>         kfail "gdb/8549" $test
>     } else {
> 	pass $test
>         gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
>     }
> }

Right, that would be an option.  After thinking about this a bit I
slightly prefer to go even one step further, like in the approach below.
In my view, it more clearly separates the steps and is more easily
extensible at the end.  But maybe I've been thinking about this too much
already ;-)

OK with this change?


set test "return from vector-valued function"
set should_kfail 0
gdb_test_multiple "return (int4) \{4, 2, 7, 6\}" $test {
    -re "#0 .* main .*$gdb_prompt $" {
	pass $test
    }
    -re "The location .* is unknown.\r\n.* return value .* will be ignored.\r\n" {
	set should_kfail 1
	exp_continue
    }
    -re "Make add_some_intvecs return now. .y or n. $" {
	send_gdb "y\n"
	exp_continue
    }
}
set test "verify vector return value"
gdb_test_multiple "continue" $test {
    -re "4 2 7 6\r\n.*$gdb_prompt $" {
	pass $test
    }
    -re "10 20 48 72\r\n.*$gdb_prompt $" {
	if { $should_kfail } {
	    kfail "gdb/8549" $test
	} else {
	    fail $test
	}
    }
}

Re: [PING][PATCH] gnu_vector.exp: Avoid some more known FAILs

[Pedro Alves]

On 08/13/2015 04:49 PM, Andreas Arnez wrote:

> Right, that would be an option.  After thinking about this a bit I
> slightly prefer to go even one step further, like in the approach below.
> In my view, it more clearly separates the steps and is more easily
> extensible at the end.  But maybe I've been thinking about this too much
> already ;-)
> 

:-)

> OK with this change?

LGTM.

Thanks,
Pedro Alves