From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OALOM5ls01+zYQAAWB0awg (envelope-from ) for ; Fri, 11 Dec 2020 07:56:57 -0500 Received: by simark.ca (Postfix, from userid 112) id D07D81F0A9; Fri, 11 Dec 2020 07:56:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI,RDNS_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 77C2F1E590 for ; Fri, 11 Dec 2020 07:56:57 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C9228385480A; Fri, 11 Dec 2020 12:56:56 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 38316385480A for ; Fri, 11 Dec 2020 12:56:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 38316385480A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 51959AC10; Fri, 11 Dec 2020 12:56:53 +0000 (UTC) Subject: Re: [PATCH][gdb/testsuite] Fix gdb.base/float128.exp with --with-mpfr=no To: Ulrich Weigand References: <20201210125334.GA1267@delia> <20201211091756.GA10227@oc3748833570.ibm.com> From: Tom de Vries Message-ID: <66b10909-4ac5-00f3-3b12-bb2b9d1f7dda@suse.de> Date: Fri, 11 Dec 2020 13:56:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201211091756.GA10227@oc3748833570.ibm.com> Content-Type: multipart/mixed; boundary="------------3B14A6C37B1796DD147B78F4" Content-Language: en-US X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" This is a multi-part message in MIME format. --------------3B14A6C37B1796DD147B78F4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/11/20 10:17 AM, Ulrich Weigand wrote: > On Thu, Dec 10, 2020 at 01:53:35PM +0100, Tom de Vries wrote: > >> When configuring gdb using --with-mpfr=no and running test-case >> gdb.base/float128.exp, we run into: >> ... >> FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!) >> ... >> >> Fix this by detecting that gdb was build without mpfr using the show >> configuration command, and changing the FAIL into UNSUPPORTED. > > That part looks OK to me, but ... > >> + if { $mpfr_supported == 0 } { >> + if { [istarget "s390*-*-*"] || [istarget "powerpc*-*-*"] } { >> + # Some of these archs have native 128-bit float support, in >> + # which case this should be passing, even without MPFR support. >> + fail $test >> + } else { >> + unsupported "$test (Missing MPFR support)" >> + } > > ... the istarget check isn't quite right - if we want a check like that, > it needs to check whether the *host* platform GDB is running on supports > native 128-bit floats; the istarget check tests the target architecture > (which will be different when testing a cross-debugging scenario). > > But I'm not sure we really need that check, I'd be fine with just always > returning unsupported here when GDB is compiled explicitly without MPFR > support (and the test fails). Ack, updated patch accordingly and committed as attached. Thanks, - Tom --------------3B14A6C37B1796DD147B78F4 Content-Type: text/x-patch; charset=UTF-8; name="0001-gdb-testsuite-Fix-gdb.base-float128.exp-with-with-mpfr-no.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="0001-gdb-testsuite-Fix-gdb.base-float128.exp-with-with-mpfr-"; filename*1="no.patch" [gdb/testsuite] Fix gdb.base/float128.exp with --with-mpfr=no When configuring gdb using --with-mpfr=no and running test-case gdb.base/float128.exp, we run into: ... FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!) ... Fix this by detecting that gdb was build without mpfr using the show configuration command, and changing the FAIL into UNSUPPORTED. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-10 Tom de Vries PR testsuite/26954 * gdb.base/float128.exp: Detect and handle no mpfr support. --- gdb/testsuite/gdb.base/float128.exp | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.base/float128.exp b/gdb/testsuite/gdb.base/float128.exp index 40babcadc1..6fe479bb94 100644 --- a/gdb/testsuite/gdb.base/float128.exp +++ b/gdb/testsuite/gdb.base/float128.exp @@ -74,6 +74,16 @@ gdb_test_multiple "set var f128=20.375l" "$test" { gdb_test "print ld" ".* = 10\\.375.*" "the value of ld is changed to 10.375" gdb_test "print f128" ".* = 20\\.375.*" "the value of f128 is changed to 20.375" +set mpfr_supported -1 +gdb_test_multiple "show configuration" "" { + -wrap -re "--with-mpfr\r\n.*" { + set mpfr_supported 1 + } + -wrap -re "--without-mpfr\r\n.*" { + set mpfr_supported 0 + } +} + # Test that we can correctly handle the largest IEEE-128 value # Note: If we get "inf" instead of the correct result, we may have run into # an internal overflow. This typically happens on host platforms without @@ -84,7 +94,17 @@ gdb_test_multiple "print large128" "$test" { pass "$test" } -re ".* = inf.*$gdb_prompt $" { - fail "$test (GDB may be missing MPFR support!)" + if { $mpfr_supported == 0 } { + # If the host platform has native 128-bit float support (as is + # the case for some versions of s390 and powerpc), the + # "print large128" test should be passing, even without MPFR + # support. So, in those cases we should have fail here rather than + # unsupported. However, given that we don't have a way to readily + # test for this, we fall back to unsupported. + unsupported "$test (Missing MPFR support)" + } else { + fail $test + } } -re ".*$gdb_prompt $" { fail "$test" --------------3B14A6C37B1796DD147B78F4--