[PATCH] Make gdb.ada/float-bits.exp more generic

[PATCH] Make gdb.ada/float-bits.exp more generic

[Luis Machado]

There are assumptions in the test about the 128-bit long double format
being used. While the results are OK for i387 128-bit long doubles, it
is not correct for IEEE quad 128-bit long doubles.

Also, depending on the target (64-bit/32-bit), 128-bit long doubles may not
be available at all. And it may be the case that the compiler for a 64-bit
target doesn't support 128-bit long doubles, but GDB might will support it
internally.

Lastly, not every 128-bit long double format has invalid values. Some formats
consider all values as valid floating point numbers.

With the above in mind, extend the test a little so it behaves well on
different architectures and so it works with different 128-bit long double
formats.

Main changes:

- Use 128-bit long double values appropriate for the long double format.
- Test 128-bit long double assignment to compiler-generated 128-bit long
  double variables.
- Test 128-bit long double assignment to GDB internal variables.

Tested on x86_64 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
---
 gdb/testsuite/gdb.ada/float-bits.exp | 70 +++++++++++++++++++++-------
 1 file changed, 52 insertions(+), 18 deletions(-)

diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp
index 4ca8dbf88e5..86ead0e87b7 100644
--- a/gdb/testsuite/gdb.ada/float-bits.exp
+++ b/gdb/testsuite/gdb.ada/float-bits.exp
@@ -25,6 +25,23 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable {debug}] != ""} {
     return -1
 }
 
+# Given EXPRESSION, return 1 if its type is 16-byte float.
+# Return 0 otherwise.
+
+proc supports_128bit_long_doubles { expression } {
+
+    set supported 0
+    gdb_test_multiple "ptype ${expression}" "" {
+	-re -wrap "<16-byte float>" {
+	    set supported 1
+	}
+	-re -wrap "<\\d+-byte float>" {
+	}
+    }
+
+    return $supported
+}
+
 clean_restart ${testfile}
 
 set bp_location [gdb_get_line_number "BREAK" ${testdir}/prog.adb]
@@ -42,29 +59,46 @@ gdb_test "print val_double := 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19"
 gdb_test "print val_double" " = -2.0e-19" \
     "print val_double after assignment"
 
-set 16llf_supported 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
-    }
+# Test if the compiler supports 128-bit long double types.
+set compiler_16llf [supports_128bit_long_doubles "long_long_float" ]
+
+# Test if GDB supports 128-bit long double types internally.
+set gdb_16llf [supports_128bit_long_doubles "16llf#0#" ]
+
+# Different architectures use different 128-bit long double formats.  For
+# example, IEEE quad x i387 128-bit long double.  Account for that in the
+# tests below.
+
+# pi in IEEE quad 128-bit long double
+set valid_128bit_float "16llf#4000921fb54442d18469898cc51701b8#"
+set printed_float "3.1415926535897932384626433832795028"
+
+if { [istarget i?86-*-*] || [istarget x86_64-*-* ] } {
+    # 5.0e+25 in i387 128-bit long double.
+    set valid_128bit_float "16llf#7FFFF7FF4054A56FA5B99019A5C8#"
+    set printed_float "5.0e\\+25"
 }
 
-if { $16llf_supported } {
-    gdb_test "print 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25"
+# Exercise GDB-side 128-bit long doubles.
+if { $gdb_16llf } {
+    gdb_test "print ${valid_128bit_float}" " = ${printed_float}"
+    gdb_test "print \$foo:=${valid_128bit_float}" "= ${printed_float}"
+    gdb_test "print \$foo" "= ${printed_float}" \
+	"print internal 128-bit long double variable after assignment"
 }
-gdb_test "print val_long_double" " = 5.0e\\+25"
-if { $16llf_supported } {
-    gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \
-	" = 5.0e\\+25"
+
+# Exercise compiler-side 128-bit long doubles.
+if { $compiler_16llf } {
+    gdb_test "print val_long_double" " = 5.0e\\+25"
+    gdb_test "print val_long_double := ${valid_128bit_float}" \
+	" = ${printed_float}"
+    gdb_test "print val_long_double" " = ${printed_float}" \
+	"print val_long_double after assignment"
 }
-gdb_test "print val_long_double" " = 5.0e\\+25" \
-    "print val_long_double after assignment"
 
-if { $16llf_supported } {
+# Some floating point formats have no invalid values, but i387
+# 128-bit long double does.
+if { [istarget i?86-*-*] || [istarget x86_64-*-* ] } {
     gdb_test "print 16llf#a56fa5b99019a5c800007ffff7ff4054#" \
 	" = <invalid float value>"
 }
-- 
2.25.1

Re: [PATCH] Make gdb.ada/float-bits.exp more generic

[Tom de Vries]

On 4/27/22 16:52, Luis Machado via Gdb-patches wrote:
> There are assumptions in the test about the 128-bit long double format
> being used. While the results are OK for i387 128-bit long doubles, it
> is not correct for IEEE quad 128-bit long doubles.
> 
> Also, depending on the target (64-bit/32-bit), 128-bit long doubles may not
> be available at all. And it may be the case that the compiler for a 64-bit
> target doesn't support 128-bit long doubles, but GDB might will support it
> internally.
> 
> Lastly, not every 128-bit long double format has invalid values. Some formats
> consider all values as valid floating point numbers.
> 
> With the above in mind, extend the test a little so it behaves well on
> different architectures and so it works with different 128-bit long double
> formats.
> 
> Main changes:
> 
> - Use 128-bit long double values appropriate for the long double format.
> - Test 128-bit long double assignment to compiler-generated 128-bit long
>    double variables.
> - Test 128-bit long double assignment to GDB internal variables.
> 
> Tested on x86_64 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).

With target board unix/-m32 on x86_64-linux, this patch regresses as 
follows:
...
(gdb) print 16llf#a56fa5b99019a5c800007ffff7ff4054#^M
Cannot export value 219902325555200000000000140737354088532 as 96-bits 
unsigned integer (must be between 0 and 79228162514264337593543950335)^M
(gdb) FAIL: gdb.ada/float-bits.exp: print 
16llf#a56fa5b99019a5c800007ffff7ff4054#
...

Note that this was fixed recently in commit 3b9809bc62c 
("[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32").

Thanks,
- Tom

Re: [PATCH] Make gdb.ada/float-bits.exp more generic

[Luis Machado]

On 5/3/22 15:53, Tom de Vries wrote:
> On 4/27/22 16:52, Luis Machado via Gdb-patches wrote:
>> There are assumptions in the test about the 128-bit long double format
>> being used. While the results are OK for i387 128-bit long doubles, it
>> is not correct for IEEE quad 128-bit long doubles.
>>
>> Also, depending on the target (64-bit/32-bit), 128-bit long doubles 
>> may not
>> be available at all. And it may be the case that the compiler for a 
>> 64-bit
>> target doesn't support 128-bit long doubles, but GDB might will 
>> support it
>> internally.
>>
>> Lastly, not every 128-bit long double format has invalid values. Some 
>> formats
>> consider all values as valid floating point numbers.
>>
>> With the above in mind, extend the test a little so it behaves well on
>> different architectures and so it works with different 128-bit long 
>> double
>> formats.
>>
>> Main changes:
>>
>> - Use 128-bit long double values appropriate for the long double format.
>> - Test 128-bit long double assignment to compiler-generated 128-bit long
>>    double variables.
>> - Test 128-bit long double assignment to GDB internal variables.
>>
>> Tested on x86_64 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
> 
> With target board unix/-m32 on x86_64-linux, this patch regresses as 
> follows:
> ...
> (gdb) print 16llf#a56fa5b99019a5c800007ffff7ff4054#^M
> Cannot export value 219902325555200000000000140737354088532 as 96-bits 
> unsigned integer (must be between 0 and 79228162514264337593543950335)^M
> (gdb) FAIL: gdb.ada/float-bits.exp: print 
> 16llf#a56fa5b99019a5c800007ffff7ff4054#

Oops. Let me update the patch to handle that particular target.

> ...
> 
> Note that this was fixed recently in commit 3b9809bc62c 
> ("[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32").
> 
> Thanks,
> - Tom

Re: [PATCH] Make gdb.ada/float-bits.exp more generic

[Pedro Alves]

On 2022-05-03 15:53, Tom de Vries via Gdb-patches wrote:
> On 4/27/22 16:52, Luis Machado via Gdb-patches wrote:
>> There are assumptions in the test about the 128-bit long double format
>> being used. While the results are OK for i387 128-bit long doubles, it
>> is not correct for IEEE quad 128-bit long doubles.
>>
>> Also, depending on the target (64-bit/32-bit), 128-bit long doubles may not
>> be available at all. And it may be the case that the compiler for a 64-bit
>> target doesn't support 128-bit long doubles, but GDB might will support it
>> internally.
>>
>> Lastly, not every 128-bit long double format has invalid values. Some formats
>> consider all values as valid floating point numbers.
>>
>> With the above in mind, extend the test a little so it behaves well on
>> different architectures and so it works with different 128-bit long double
>> formats.
>>
>> Main changes:
>>
>> - Use 128-bit long double values appropriate for the long double format.
>> - Test 128-bit long double assignment to compiler-generated 128-bit long
>>    double variables.
>> - Test 128-bit long double assignment to GDB internal variables.
>>
>> Tested on x86_64 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
> 
> With target board unix/-m32 on x86_64-linux, this patch regresses as follows:
> ...
> (gdb) print 16llf#a56fa5b99019a5c800007ffff7ff4054#^M
> Cannot export value 219902325555200000000000140737354088532 as 96-bits unsigned integer (must be between 0 and 79228162514264337593543950335)^M
> (gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#a56fa5b99019a5c800007ffff7ff4054#
> ...
> 
> Note that this was fixed recently in commit 3b9809bc62c ("[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32").

It's a bit annoying to have to discovered issues such as this that don't depend
on a running program, by running the test on different architectures.
Would it make sense to have this test iterate over all supported architectures, like
was done to gdb.base/parse_number.exp?  GDB nowadays can parse and print floats
for the target via MFPR (gdb/target-float.c), so maybe it would work.

[PATCH,v2] Make gdb.ada/float-bits.exp more generic

[Luis Machado]

v2:

- Reworked the testcase some more to exercise 128-bit i387 long doubles,
  80-bit i387 long doubles and 128-bit IEEE quad long doubles.

--

There are assumptions in the test about the long double format
being used. While the results are OK for i387 128-bit long doubles, it
is not correct for IEEE quad 128-bit long doubles.

Also, depending on the target (64-bit/32-bit), long doubles may not
be available at all. And it may be the case that the compiler for a 64-bit
target doesn't support 128-bit long doubles, but GDB might still support it
internally.

Lastly, not every long double format has invalid values. Some formats
consider all values as valid floating point numbers.

These divergences cause the following FAIL's on aarch64/arm:

FAIL: gdb.ada/float-bits.exp: print val_long_double
FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment

With the above in mind, extend the test a little so it behaves well on
different architectures and so it works with different long double
formats.

Main changes:

- Use long double values appropriate for the long double format.
- Test long double assignment to compiler-generated long
  double variables.
- Test long double assignment to GDB internal variables.

Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
---
 gdb/testsuite/gdb.ada/float-bits.exp | 87 ++++++++++++++++++++++------
 1 file changed, 68 insertions(+), 19 deletions(-)

diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp
index 4ca8dbf88e5..b59f8d00f43 100644
--- a/gdb/testsuite/gdb.ada/float-bits.exp
+++ b/gdb/testsuite/gdb.ada/float-bits.exp
@@ -25,6 +25,27 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable {debug}] != ""} {
     return -1
 }
 
+# Given a floating point EXPRESSION, return the size of # the result.
+
+proc float_size { expression } {
+
+    set size 0
+    gdb_test_multiple "ptype ${expression}" "" {
+	-re -wrap "<16-byte float>" {
+	    set size 16
+	}
+	-re -wrap "<12-byte float>" {
+	    set size 12
+	}
+	-re -wrap "<\\d+-byte float>" {
+	    # Assume 8 for anything less than or equal to 8.
+	    set size 8
+	}
+    }
+
+    return $size
+}
+
 clean_restart ${testfile}
 
 set bp_location [gdb_get_line_number "BREAK" ${testdir}/prog.adb]
@@ -42,29 +63,57 @@ gdb_test "print val_double := 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19"
 gdb_test "print val_double" " = -2.0e-19" \
     "print val_double after assignment"
 
-set 16llf_supported 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
+# Fetch the size of a compiler-generated long double.
+set compiler_long_double_size [float_size "long_long_float" ]
+
+# Fetch the size of an internal long double type in GDB.
+set gdb_long_double_size [float_size "16llf#0#" ]
+
+# Different architectures use different long double formats.  For
+# example, IEEE quad versus i387 long doubles.  Account for that in the
+# tests below.
+
+# Set default values for 128-bit IEEE quad long doubles.
+set valid_long_double "16llf#4000921fb54442d18469898cc51701b8#"
+set printed_long_double "3.1415926535897932384626433832795028"
+set invalid_long_double ""
+set has_invalid_long_double 0
+
+if { [istarget x86_64-*-* ] || [istarget i?86-*-*] } {
+    # i387 long double have invalid values
+    set has_invalid_long_double 1
+    if { $compiler_long_double_size == 16 } {
+	# 5.0e+25 in i387 128-bit long double.
+	set valid_long_double "16llf#7ffff7ff4054a56fa5b99019a5c8#"
+	set invalid_long_double "16llf#a56fa5b99019a5c800007ffff7ff4054#"
+	set printed_long_double "5.0e\\+25"
+    } elseif { $compiler_long_double_size == 12 } {
+	# 5.0e+25 in i387 80-bit long double.
+	set valid_long_double "16llf#56554054a56fa5b99019a5c8#"
+	set invalid_long_double "16llf#9019a5c800007ffff7ff4054#"
+	set printed_long_double "5.0e\\+25"
     }
 }
 
-if { $16llf_supported } {
-    gdb_test "print 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25"
+# Exercise GDB-side long doubles.
+if { $gdb_long_double_size > 8 } {
+    gdb_test "print ${valid_long_double}" " = ${printed_long_double}"
+    gdb_test "print \$foo:=${valid_long_double}" "= ${printed_long_double}"
+    gdb_test "print \$foo" "= ${printed_long_double}" \
+	"print internal long double variable after assignment"
 }
-gdb_test "print val_long_double" " = 5.0e\\+25"
-if { $16llf_supported } {
-    gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \
-	" = 5.0e\\+25"
+
+# Exercise compiler-side long doubles.
+if { $compiler_long_double_size > 8 } {
+    gdb_test "print val_long_double" " = 5.0e\\+25"
+    gdb_test "print val_long_double := ${valid_long_double}" \
+	" = ${printed_long_double}"
+    gdb_test "print val_long_double" " = ${printed_long_double}" \
+	"print val_long_double after assignment"
 }
-gdb_test "print val_long_double" " = 5.0e\\+25" \
-    "print val_long_double after assignment"
 
-if { $16llf_supported } {
-    gdb_test "print 16llf#a56fa5b99019a5c800007ffff7ff4054#" \
-	" = <invalid float value>"
+# If the target has invalid long double values, test it now.
+if { $has_invalid_long_double } {
+    gdb_test "print ${invalid_long_double}" \
+	" = <invalid float value>" "print invalid long double value"
 }
-- 
2.25.1

Re: [PATCH,v2] Make gdb.ada/float-bits.exp more generic

[Tom de Vries]

On 5/11/22 15:00, Luis Machado wrote:
> v2:
> 
> - Reworked the testcase some more to exercise 128-bit i387 long doubles,
>    80-bit i387 long doubles and 128-bit IEEE quad long doubles.
> 

Hi,

apart from nit below, LGTM.

I've also tested it on x86_64, x86_64/-m32 and aarch64.

Thanks,
- Tom

> --
> 
> There are assumptions in the test about the long double format
> being used. While the results are OK for i387 128-bit long doubles, it
> is not correct for IEEE quad 128-bit long doubles.
> 
> Also, depending on the target (64-bit/32-bit), long doubles may not
> be available at all. And it may be the case that the compiler for a 64-bit
> target doesn't support 128-bit long doubles, but GDB might still support it
> internally.
> 
> Lastly, not every long double format has invalid values. Some formats
> consider all values as valid floating point numbers.
> 
> These divergences cause the following FAIL's on aarch64/arm:
> 
> FAIL: gdb.ada/float-bits.exp: print val_long_double
> FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
> 
> With the above in mind, extend the test a little so it behaves well on
> different architectures and so it works with different long double
> formats.
> 
> Main changes:
> 
> - Use long double values appropriate for the long double format.
> - Test long double assignment to compiler-generated long
>    double variables.
> - Test long double assignment to GDB internal variables.
> 
> Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).
> ---
>   gdb/testsuite/gdb.ada/float-bits.exp | 87 ++++++++++++++++++++++------
>   1 file changed, 68 insertions(+), 19 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp
> index 4ca8dbf88e5..b59f8d00f43 100644
> --- a/gdb/testsuite/gdb.ada/float-bits.exp
> +++ b/gdb/testsuite/gdb.ada/float-bits.exp
> @@ -25,6 +25,27 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable {debug}] != ""} {
>       return -1
>   }
>   
> +# Given a floating point EXPRESSION, return the size of # the result.

of '#' the -> of the

> +
> +proc float_size { expression } {
> +
> +    set size 0
> +    gdb_test_multiple "ptype ${expression}" "" {
> +	-re -wrap "<16-byte float>" {
> +	    set size 16
> +	}
> +	-re -wrap "<12-byte float>" {
> +	    set size 12
> +	}
> +	-re -wrap "<\\d+-byte float>" {
> +	    # Assume 8 for anything less than or equal to 8.
> +	    set size 8
> +	}
> +    }
> +
> +    return $size
> +}
> +
>   clean_restart ${testfile}
>   
>   set bp_location [gdb_get_line_number "BREAK" ${testdir}/prog.adb]
> @@ -42,29 +63,57 @@ gdb_test "print val_double := 16lf#bc0d83c94fb6d2ac#" " = -2.0e-19"
>   gdb_test "print val_double" " = -2.0e-19" \
>       "print val_double after assignment"
>   
> -set 16llf_supported 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
> +# Fetch the size of a compiler-generated long double.
> +set compiler_long_double_size [float_size "long_long_float" ]
> +
> +# Fetch the size of an internal long double type in GDB.
> +set gdb_long_double_size [float_size "16llf#0#" ]
> +
> +# Different architectures use different long double formats.  For
> +# example, IEEE quad versus i387 long doubles.  Account for that in the
> +# tests below.
> +
> +# Set default values for 128-bit IEEE quad long doubles.
> +set valid_long_double "16llf#4000921fb54442d18469898cc51701b8#"
> +set printed_long_double "3.1415926535897932384626433832795028"
> +set invalid_long_double ""
> +set has_invalid_long_double 0
> +
> +if { [istarget x86_64-*-* ] || [istarget i?86-*-*] } {
> +    # i387 long double have invalid values
> +    set has_invalid_long_double 1
> +    if { $compiler_long_double_size == 16 } {
> +	# 5.0e+25 in i387 128-bit long double.
> +	set valid_long_double "16llf#7ffff7ff4054a56fa5b99019a5c8#"
> +	set invalid_long_double "16llf#a56fa5b99019a5c800007ffff7ff4054#"
> +	set printed_long_double "5.0e\\+25"
> +    } elseif { $compiler_long_double_size == 12 } {
> +	# 5.0e+25 in i387 80-bit long double.
> +	set valid_long_double "16llf#56554054a56fa5b99019a5c8#"
> +	set invalid_long_double "16llf#9019a5c800007ffff7ff4054#"
> +	set printed_long_double "5.0e\\+25"
>       }
>   }
>   
> -if { $16llf_supported } {
> -    gdb_test "print 16llf#7FFFF7FF4054A56FA5B99019A5C8#" " = 5.0e\\+25"
> +# Exercise GDB-side long doubles.
> +if { $gdb_long_double_size > 8 } {
> +    gdb_test "print ${valid_long_double}" " = ${printed_long_double}"
> +    gdb_test "print \$foo:=${valid_long_double}" "= ${printed_long_double}"
> +    gdb_test "print \$foo" "= ${printed_long_double}" \
> +	"print internal long double variable after assignment"
>   }
> -gdb_test "print val_long_double" " = 5.0e\\+25"
> -if { $16llf_supported } {
> -    gdb_test "print val_long_double := 16llf#7FFFF7FF4054A56FA5B99019A5C8#" \
> -	" = 5.0e\\+25"
> +
> +# Exercise compiler-side long doubles.
> +if { $compiler_long_double_size > 8 } {
> +    gdb_test "print val_long_double" " = 5.0e\\+25"
> +    gdb_test "print val_long_double := ${valid_long_double}" \
> +	" = ${printed_long_double}"
> +    gdb_test "print val_long_double" " = ${printed_long_double}" \
> +	"print val_long_double after assignment"
>   }
> -gdb_test "print val_long_double" " = 5.0e\\+25" \
> -    "print val_long_double after assignment"
>   
> -if { $16llf_supported } {
> -    gdb_test "print 16llf#a56fa5b99019a5c800007ffff7ff4054#" \
> -	" = <invalid float value>"
> +# If the target has invalid long double values, test it now.
> +if { $has_invalid_long_double } {
> +    gdb_test "print ${invalid_long_double}" \
> +	" = <invalid float value>" "print invalid long double value"
>   }

Re: [PATCH,v2] Make gdb.ada/float-bits.exp more generic

[Luis Machado]

On 5/12/22 10:14, Tom de Vries wrote:
> On 5/11/22 15:00, Luis Machado wrote:
>> v2:
>>
>> - Reworked the testcase some more to exercise 128-bit i387 long doubles,
>>    80-bit i387 long doubles and 128-bit IEEE quad long doubles.
>>
> 
> Hi,
> 
> apart from nit below, LGTM.
> 
> I've also tested it on x86_64, x86_64/-m32 and aarch64.

Thanks for testing.

> 
> Thanks,
> - Tom
> 
>> -- 
>>
>> There are assumptions in the test about the long double format
>> being used. While the results are OK for i387 128-bit long doubles, it
>> is not correct for IEEE quad 128-bit long doubles.
>>
>> Also, depending on the target (64-bit/32-bit), long doubles may not
>> be available at all. And it may be the case that the compiler for a 
>> 64-bit
>> target doesn't support 128-bit long doubles, but GDB might still 
>> support it
>> internally.
>>
>> Lastly, not every long double format has invalid values. Some formats
>> consider all values as valid floating point numbers.
>>
>> These divergences cause the following FAIL's on aarch64/arm:
>>
>> FAIL: gdb.ada/float-bits.exp: print val_long_double
>> FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment
>>
>> With the above in mind, extend the test a little so it behaves well on
>> different architectures and so it works with different long double
>> formats.
>>
>> Main changes:
>>
>> - Use long double values appropriate for the long double format.
>> - Test long double assignment to compiler-generated long
>>    double variables.
>> - Test long double assignment to GDB internal variables.
>>
>> Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm 
>> (9 PASS).
>> ---
>>   gdb/testsuite/gdb.ada/float-bits.exp | 87 ++++++++++++++++++++++------
>>   1 file changed, 68 insertions(+), 19 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.ada/float-bits.exp 
>> b/gdb/testsuite/gdb.ada/float-bits.exp
>> index 4ca8dbf88e5..b59f8d00f43 100644
>> --- a/gdb/testsuite/gdb.ada/float-bits.exp
>> +++ b/gdb/testsuite/gdb.ada/float-bits.exp
>> @@ -25,6 +25,27 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" 
>> executable {debug}] != ""} {
>>       return -1
>>   }
>> +# Given a floating point EXPRESSION, return the size of # the result.
> 
> of '#' the -> of the
> 

This was fixed locally. Pushed now!