From: Luis Machado <luis.machado@arm.com>
To: Tom Tromey <tromey@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/3] Implement real literal extension for Ada
Date: Tue, 29 Mar 2022 09:13:01 +0100 [thread overview]
Message-ID: <0c2acc0f-a6aa-d063-5d9c-0c129954d811@arm.com> (raw)
In-Reply-To: <429bc573-999a-86d7-cf70-bb685c7f457d@arm.com>
Hi,
On 3/21/22 09:28, Luis Machado via Gdb-patches wrote:
> Hi Tom,
>
> On 3/18/22 18:05, Tom Tromey wrote:
>>>>>>> "Luis" == Luis Machado <luis.machado@arm.com> writes:
>>
>> Luis> I think the floating point representations may differ between
>> Luis> architectures/bit-sizes.
>>
>> Luis> I noticed 5 failures in this test for aarch64-linux and arm-linux.
>>
>> This is interesting, because internally we have a rewrite of this same
>> test, and it seems fine on aarch64-linux.
>>
>> Luis> FAIL: gdb.ada/float-bits.exp: print
>> 16llf#7FFFF7FF4054A56FA5B99019A5C8#
>> Luis> FAIL: gdb.ada/float-bits.exp: print val_long_double
>> Luis> FAIL: gdb.ada/float-bits.exp: print val_long_double :=
>> Luis> 16llf#7FFFF7FF4054A56FA5B99019A5C8#
>> Luis> FAIL: gdb.ada/float-bits.exp: print val_long_double after
>> assignment
>> Luis> FAIL: gdb.ada/float-bits.exp: print
>>
>> Luis> Some of the expected values don't really match. If the output is
>> Luis> supposed to differ, maybe we should compare hex values instead?
>>
>> I'm curious what is show by 'print/x' of the various values in there.
>
> Here's what I see on my end:
>
> (gdb) p/x 16llf#7FFFF7FF4054A56FA5B99019A5C8#
> $9 = 0x7ffff7ff4054a56fa5b99019a5c8
>
> (gdb) p/x val_long_double
> $10 = 0x4544adf4b7320335
>
> (gdb) p/x val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#
> $11 = 0x0
>
> (gdb) p/x val_long_double
> $12 = 0x0
>
> (gdb) p/x 16llf#a56fa5b99019a5c800007ffff7ff4054#
> $13 = 0xa56fa5b99019a5c800007ffff7ff4054
>
> (gdb) ptype val_long_double
> type = <8-byte float>
>
> (gdb) ptype 16llf#a56fa5b99019a5c800007ffff7ff4054#
> type = <16-byte float>
>
>>
>> Luis> Also, for 32-bit targets, I'm seeing size-related issues.
>>
>> We're also doing testing on ARM and that seems fine.
>>
>
> Interesting. I wonder what's different in my environment then. This is
> standard Ubuntu 20.04 on aarch64 hardware.
>
> I usually build --enable-targets=all, but in this case I tried a single
> target and it did not change things.
>
>> I did disable some of these internally for some targets, ones with
>> "weird" floating point.
>>
>> Anyway, it seems like we could change the test to verify that the size
>> of each floating point type is what's expected before proceeding. But
>> I'd like to understand the above a bit better, first.
>
> Please let me know if you'd like the full log and/or some more information.
Did you have a chance to check things on your end?
next prev parent reply other threads:[~2022-03-29 8:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 17:00 [PATCH 0/3] Floating-point literal syntax " Tom Tromey
2022-03-01 17:00 ` [PATCH 1/3] Fix Ada integer literals with exponents Tom Tromey
2022-03-01 17:00 ` [PATCH 2/3] Implement real literal extension for Ada Tom Tromey
2022-03-01 17:22 ` Eli Zaretskii
2022-03-07 15:28 ` Tom Tromey
2022-03-16 14:33 ` Luis Machado
2022-03-18 18:05 ` Tom Tromey
2022-03-21 9:28 ` Luis Machado
2022-03-29 8:13 ` Luis Machado [this message]
2022-03-01 17:00 ` [PATCH 3/3] Fix bug in ada_print_floating Tom Tromey
2022-03-07 15:28 ` [PATCH 0/3] Floating-point literal syntax extension for Ada Tom Tromey
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=0c2acc0f-a6aa-d063-5d9c-0c129954d811@arm.com \
--to=luis.machado@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@adacore.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).