From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Luis Machado <luis.machado@arm.com>, gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH][gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32
Date: Mon, 2 May 2022 09:10:36 +0200 [thread overview]
Message-ID: <98208d6d-817d-b3a8-aebf-d56ac33ff40e@suse.de> (raw)
In-Reply-To: <2ce6644a-6480-8a78-b53c-c2321956f3d8@arm.com>
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?
next prev parent reply other threads:[~2022-05-02 7:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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
2022-05-02 7:10 ` Tom de Vries via Gdb-patches [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98208d6d-817d-b3a8-aebf-d56ac33ff40e@suse.de \
--to=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--cc=tdevries@suse.de \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox