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

[Luis Machado via Gdb-patches <gdb-patches@sourceware.org>]

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.