From patchwork Tue Jan 19 18:46:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Arnez X-Patchwork-Id: 10460 Received: (qmail 124793 invoked by alias); 19 Jan 2016 18:46:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 124777 invoked by uid 89); 19 Jan 2016 18:46:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=gnu_vector.exp, gnu_vectorexp, UD:gnu_vector.exp X-HELO: e06smtp09.uk.ibm.com Received: from e06smtp09.uk.ibm.com (HELO e06smtp09.uk.ibm.com) (195.75.94.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 19 Jan 2016 18:46:25 +0000 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Jan 2016 18:46:22 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 19 Jan 2016 18:46:21 -0000 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id DA1212190023 for ; Tue, 19 Jan 2016 18:46:08 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0JIkKf1065940 for ; Tue, 19 Jan 2016 18:46:20 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0JIkKxc011171 for ; Tue, 19 Jan 2016 11:46:20 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-188.boeblingen.de.ibm.com [9.152.212.188]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u0JIkKDS011094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2016 11:46:20 -0700 From: Andreas Arnez To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gnu_vector.exp: Respect `should_kfail' for PR8549 References: <864me9tqxc.fsf@gmail.com> Date: Tue, 19 Jan 2016 19:46:19 +0100 In-Reply-To: <864me9tqxc.fsf@gmail.com> (Yao Qi's message of "Tue, 19 Jan 2016 17:33:35 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16011918-0037-0000-0000-000005504806 X-IsSubscribed: yes On Tue, Jan 19 2016, Yao Qi wrote: > Andreas Arnez writes: > >> -gdb_test "p res" "\\{4, 2, 7, 6\\}.*" "verify vector return value" >> +set test "verify vector return value" >> +gdb_test_multiple "p res" $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 >> + } >> + } >> +} > > IMO, if GDB for a certain target doesn't handle "return" and "finish" > correctly, the return value can be some random results. Why do we match > "\\{10, 20, 48, 72\\}" here? I presume that because "10, 20, 48, 72" > was returned in the previous test. Do *all* targets don't correctly handle > "return" and "finish" return "\\{10, 20, 48, 72\\}"? In other words, if > we know it is broken already, why do still match the output? We can > kfail it according to the target triplet. Doing the KFAIL based on the target triplet would miss the point of this test on s390x, because on the same target "s390x-ibm-linux-gnu" the test shall succeed if the CPU has vector registers and the vector ABI is used, but is known to fail if a non-vector ABI is used. (Note that the main reason for enhancing the gnu_vector test case was to verify GDB's correct treatment of the s390x vector ABI.) But testing against some expected return value in this case is certainly wrong. I suggest to change my patch like follows. WDYT? diff --git a/gdb/testsuite/gdb.base/gnu_vector.exp b/gdb/testsuite/gdb.base/gnu_vector.exp index 127c0b7..c911830 100644 --- a/gdb/testsuite/gdb.base/gnu_vector.exp +++ b/gdb/testsuite/gdb.base/gnu_vector.exp @@ -245,7 +245,7 @@ gdb_test_multiple "p res" $test { -re ".*= \\{4, 2, 7, 6\\}\r\n.*$gdb_prompt $" { pass $test } - -re ".*= \\{10, 20, 48, 72\\}\r\n.*$gdb_prompt $" { + -re ".*= \\{.*\\}\r\n.*$gdb_prompt $" { if { $should_kfail } { kfail "gdb/8549" $test } else {