* [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 @ 2022-04-14 13:14 Tom de Vries via Gdb-patches 2022-04-15 15:30 ` Tom Tromey via Gdb-patches 2022-04-25 10:31 ` Luis Machado via Gdb-patches 0 siblings, 2 replies; 7+ messages in thread From: Tom de Vries via Gdb-patches @ 2022-04-14 13:14 UTC (permalink / raw) To: gdb-patches; +Cc: Tom Tromey 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. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29041 Any comments? Thanks, - Tom [gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 --- gdb/testsuite/gdb.ada/float-bits.exp | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp index c98afb53c06..4ca8dbf88e5 100644 --- a/gdb/testsuite/gdb.ada/float-bits.exp +++ b/gdb/testsuite/gdb.ada/float-bits.exp @@ -42,12 +42,29 @@ 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 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25" +set 16llf_supported 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 + } +} + +if { $16llf_supported } { + gdb_test "print 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25" +} gdb_test "print val_long_double" " = 5.0e\\+25" -gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \ - " = 5.0e\\+25" +if { $16llf_supported } { + gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \ + " = 5.0e\\+25" +} gdb_test "print val_long_double" " = 5.0e\\+25" \ "print val_long_double after assignment" -gdb_test "print 16llf#a56fa5b99019a5c800007ffff7ff4054#" \ - " = <invalid float value>" +if { $16llf_supported } { + gdb_test "print 16llf#a56fa5b99019a5c800007ffff7ff4054#" \ + " = <invalid float value>" +} ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-04-14 13:14 [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 Tom de Vries via Gdb-patches @ 2022-04-15 15:30 ` Tom Tromey via Gdb-patches 2022-04-25 10:31 ` Luis Machado via Gdb-patches 1 sibling, 0 replies; 7+ messages in thread From: Tom Tromey via Gdb-patches @ 2022-04-15 15:30 UTC (permalink / raw) To: Tom de Vries via Gdb-patches; +Cc: Tom Tromey Tom> Fix this by testing whether 16llf is supported by doing ptype long_long_float Tom> which gets us either: Tom> ... Tom> type = <16-byte float>^M Tom> ... Tom> or: Tom> ... Tom> type = <12-byte float>^M Tom> ... Looks reasonable to me. Thank you for doing this. Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-04-14 13:14 [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 Tom de Vries via Gdb-patches 2022-04-15 15:30 ` Tom Tromey via Gdb-patches @ 2022-04-25 10:31 ` Luis Machado via Gdb-patches 2022-05-02 7:10 ` Tom de Vries via Gdb-patches 1 sibling, 1 reply; 7+ messages in thread From: Luis Machado via Gdb-patches @ 2022-04-25 10:31 UTC (permalink / raw) To: Tom de Vries, gdb-patches; +Cc: Tom Tromey 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. FAIL: gdb.ada/float-bits.exp: print val_long_double FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment 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. I'm guessing some 16ll tests still work for 12-byte floats, right? What do you think? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-04-25 10:31 ` Luis Machado via Gdb-patches @ 2022-05-02 7:10 ` Tom de Vries via Gdb-patches 2022-05-03 6:47 ` Luis Machado via Gdb-patches 0 siblings, 1 reply; 7+ messages in thread From: Tom de Vries via Gdb-patches @ 2022-05-02 7:10 UTC (permalink / raw) To: Luis Machado, gdb-patches; +Cc: Tom Tromey 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. > 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 ). > 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. Thanks, - Tom > I'm guessing some 16ll tests still work for 12-byte floats, right? > > What do you think? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-05-02 7:10 ` Tom de Vries via Gdb-patches @ 2022-05-03 6:47 ` Luis Machado via Gdb-patches 2022-05-03 10:54 ` Tom de Vries via Gdb-patches 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado via Gdb-patches @ 2022-05-03 6:47 UTC (permalink / raw) To: Tom de Vries, gdb-patches; +Cc: Tom Tromey 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" 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 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? > > Thanks, > - Tom > >> I'm guessing some 16ll tests still work for 12-byte floats, right? >> >> What do you think? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-05-03 6:47 ` Luis Machado via Gdb-patches @ 2022-05-03 10:54 ` Tom de Vries via Gdb-patches 2022-05-03 11:09 ` Luis Machado via Gdb-patches 0 siblings, 1 reply; 7+ messages in thread From: Tom de Vries via Gdb-patches @ 2022-05-03 10:54 UTC (permalink / raw) To: Luis Machado, gdb-patches; +Cc: Tom Tromey 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 2022-05-03 10:54 ` Tom de Vries via Gdb-patches @ 2022-05-03 11:09 ` Luis Machado via Gdb-patches 0 siblings, 0 replies; 7+ messages in thread From: Luis Machado via Gdb-patches @ 2022-05-03 11:09 UTC (permalink / raw) To: Tom de Vries, gdb-patches; +Cc: Tom Tromey On 5/3/22 11:54, Tom de Vries wrote: > 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. > No worries. I assumed so. It's just that I decided to go ahead and improve the test somewhat, and the improvement seemed beyond what this patch touched. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-05-03 11:10 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-14 13:14 [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32 Tom de Vries via Gdb-patches 2022-04-15 15:30 ` Tom Tromey via Gdb-patches 2022-04-25 10:31 ` Luis Machado via Gdb-patches 2022-05-02 7:10 ` Tom de Vries via Gdb-patches 2022-05-03 6:47 ` Luis Machado via Gdb-patches 2022-05-03 10:54 ` Tom de Vries via Gdb-patches 2022-05-03 11:09 ` Luis Machado via Gdb-patches
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox