From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D73C03857C50 for ; Tue, 3 May 2022 10:54:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D73C03857C50 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 12F371F38D; Tue, 3 May 2022 10:54:18 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E2B6913ABE; Tue, 3 May 2022 10:54:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id QXfANdkJcWIYAgAAMHmgww (envelope-from ); Tue, 03 May 2022 10:54:17 +0000 Message-ID: <4abe9008-4a35-8e14-0f6e-2cddd3964f83@suse.de> Date: Tue, 3 May 2022 12:54:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 Content-Language: en-US To: Luis Machado , gdb-patches@sourceware.org Cc: Tom Tromey References: <20220414131412.GA9234@delia> <2ce6644a-6480-8a78-b53c-c2321956f3d8@arm.com> <98208d6d-817d-b3a8-aebf-d56ac33ff40e@suse.de> <0d550247-8ac6-6ff7-c025-c303e2883ed5@arm.com> From: Tom de Vries In-Reply-To: <0d550247-8ac6-6ff7-c025-c303e2883ed5@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, URI_DOTEDU autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 03 May 2022 10:54:20 -0000 On 5/3/22 08:47, Luis Machado wrote: > On 5/2/22 08:10, Tom de Vries wrote: >> On 4/25/22 12:31, Luis Machado wrote: >>> On 4/14/22 14:14, Tom de Vries via Gdb-patches wrote: >>>> Hi, >>>> >>>> With test-case gdb.ada/float-bits.exp and native we get: >>>> ... >>>> (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M >>>> $9 = 5.0e+25^M >>>> (gdb) PASS: gdb.ada/float-bits.exp: print >>>> 16llf#7FFFF7FF4054A56FA5B99019A5C8# >>>> ... >>>> but with target board unix/-m32 we have instead: >>>> ... >>>> (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M >>>> Cannot export value 2596145952482202326224873165792712 as 96-bits \ >>>>    unsigned integer (must be between 0 and >>>> 79228162514264337593543950335)^M >>>> (gdb) FAIL: gdb.ada/float-bits.exp: print >>>> 16llf#7FFFF7FF4054A56FA5B99019A5C8# >>>> ... >>>> >>>> Fix this by testing whether 16llf is supported by doing ptype >>>> long_long_float >>>> which gets us either: >>>> ... >>>> type = <16-byte float>^M >>>> ... >>>> or: >>>> ... >>>> type = <12-byte float>^M >>>> ... >>>> >>>> Tested on x86_64-linux with native and unix/-m32. >>> >>> Unfortunately not all targets support 128-bit long doubles. For arm >>> and aarch64 the compiler won't generate a 128-bit float, but a 64-bit >>> float, so the 16ll tests won't be meaningful. >>> >> >> Right, but I'd expect those tests are skipped because 16llf_supported >> is 0 for 64-bit long double. > > They are skipped, but the testcase still assumes some 16llf tests can be > executed: > > gdb_test "print val_long_double" " = 5.0e\\+25" > > gdb_test "print val_long_double" " = 5.0e\\+25" \ >     "print val_long_double after assignment" > Ah, I see, you mean the val_long_double tests that do not use 16llf. > The above couple tests won't work correctly, as you're trying to force a > 128-bit value into a 64-bit variable. >> >>> FAIL: gdb.ada/float-bits.exp: print val_long_double >>> FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment >>> >> >> Can you show me the actual failure mode, that is, copy from gdb.log >> instead of gdb.sum?  I'm surprised that these fail because AFAICT, the >> used constant: 5.0e+25 is exactly representable in 64-bit ieee ( I >> used https://babbage.cs.qc.cuny.edu/ieee-754.old/decimal.html to check >> this ). > > Sure, here it is: > > print val_long_double > $9 = 5.0000000000000002e+25 > (gdb) FAIL: gdb.ada/float-bits.exp: print val_long_double > print val_long_double > $10 = 5.0000000000000002e+25 > (gdb) FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment > >> I see. I can reproduce this using reproducer patch posted below, which gives me: ... (gdb) print val_double_2^M $9 = 5.0000000000000002e+25^M (gdb) print /x val_double_2^M $10 = 0x4544adf4b7320335^M (gdb) ... So, I realize now that my statement about it being exactly representable was incorrect, it's represented as 2^85 * 1.2924697071141058. I was thrown off by the website presenting me a crisp '5.0000000000000000e+25' as the value, but that's just one way to print it, and glibc evidently uses a different rounding in printing, which is allowed AFAICT, as per 'The low-order digit shall be rounded in an implementation-defined manner'. So I suppose we could just accept " = (5.0e\+25|5.000000000000000\de\+25)" for 64-bits long double. >>> I wonder if it would be best to bail out as soon as we find out the >>> target has no support for 128-bit floats. I can write a patch for that. >>> >> >> With a rewrite like this: >> ... >> -set 16llf_supported 0 >> +set long_double_bytes 0 >>   gdb_test_multiple "ptype long_long_float" "" { >> -    -re -wrap "<16-byte float>" { >> -       set 16llf_supported 1 >> -       pass $gdb_test_name >> -    } >> -    -re -wrap "<\\d+-byte float>" { >> -       pass $gdb_test_name >> +    -re -wrap "<\(\\d+\)-byte float>" { >> +       set long_double_bytes $expect_out(1,string) >>       } >>   } >> >> +set 16llf_supported [expr $long_double_bytes >= 16] >> ... >> we can formulate the precondition for any test in terms number of long >> double bytes. > > I've sent a patch to make this test a bit more generic: > https://sourceware.org/pipermail/gdb-patches/2022-April/188440.html > > Did you see it? > I did not, I've just come back from vacation and am still working through my inbox (and you didn't post the patch in reply to this thread, or cc-ed me, or updated this thread with a reference-to-post, any of which would mean I would have some pointer in my inbox) . I'll take a look. Thanks, - Tom >> >> Thanks, >> - Tom >> >>> I'm guessing some 16ll tests still work for 12-byte floats, right? >>> >>> What do you think? > ---------- diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp index 4ca8dbf88e5..937e307f8b4 100644 --- a/gdb/testsuite/gdb.ada/float-bits.exp +++ b/gdb/testsuite/gdb.ada/float-bits.exp @@ -42,6 +42,9 @@ gdb_test "print val_double := 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19" gdb_test "print val_double" " = -2.0e-19" \ "print val_double after assignment" +gdb_test "print val_double_2" +gdb_test "print /x val_double_2" + set 16llf_supported 0 gdb_test_multiple "ptype long_long_float" "" { -re -wrap "<16-byte float>" { diff --git a/gdb/testsuite/gdb.ada/float-bits/prog.adb b/gdb/testsuite/gdb.ada/float-bits/p rog.adb index 0d8c18f8d47..001bf0bb3b9 100644 --- a/gdb/testsuite/gdb.ada/float-bits/prog.adb +++ b/gdb/testsuite/gdb.ada/float-bits/prog.adb @@ -16,6 +16,7 @@ procedure Prog is Val_Float : Float := 23.0; Val_Double : Long_Float := -2.0e-19; + Val_Double_2 : Long_Float := 5.0e+25; Val_Long_Double : Long_Long_Float := 5.0e+25; begin null; -- BREAK