Re: [PATCH 2/3] Implement real literal extension for Ada

Luis Machado via Gdb-patches
2022-03-29T08:13:59Z

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?