Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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?

  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