[gdb/testsuite] Fix gdb.base/long_long.exp on arm

On armv7hl-suse-linux-gnu, I run into:
...
(gdb) p/f val.oct
$26 = -5.9822653797615723e-120
(gdb) FAIL: gdb.base/long_long.exp: p/f val.oct
...

There's some complicated logic here in the test-case:
...
if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
    # ARM FPA floating point numbers are not strictly little endian or big
    # endian, but a hybrid.  They are in little endian format with the two
    # words swapped in big endian format.
    # EABI targets default to natural-endian VFP format.

    if { ([istarget "arm*-*-*"]) \
	 && !([istarget "*-*-*eabi*"] || \
	      [istarget "*-*-mingw32ce*"] || \
	      [istarget "*-*-openbsd*"]) } then {
	# assume the long long represents a floating point double in ARM format
	gdb_test "p/f val.oct" "2.1386676354387559e\\+265"
    } else {
	# assume the long long represents a floating point double in little
	# endian format
	gdb_test "p/f val.oct" "-5.9822653797615723e-120"
    }
} else {
    gdb_test "p/f val.oct" "-2.42716126e-15"
}
...
which makes the test-case expect the ARM FPA variant.

I think trying to pin down the exact circumstances under which we have ARM FPA
is unnecessary, so I could live with:
...
    set re_val_oct_f [string_to_regexp "-5.9822653797615723e-120"]
    if { [istarget "arm*-*-*"] } {
        set re_val_oct_f_arm_fpa [string_to_regexp "2.1386676354387559e+265"]
	re_val_oct_f "$re_val_oct_f|$re_val_oct_f_arm_fpa"
    }
....

But instead, I propose to just drop the arm-specific part.

I doubt whether an ARM VPA setup is still part of any test matrix.  And if it
is, then I expect other tests to fail as well for the same reason.  The ARM
FPA logic is used only once in the test-case, but -5.9822653797615723e-120 is
used more frequently.

Indeed, I wonder the same about setups where -2.42716126e-15 is expected.
On such a setup, won't this fail as well:
...
gdb_test "x/2gf g" "3.5127005640885037e-303.*-5.9822653797615723e-120"
...
?

Unfortunately I'm not sure what setup to use to trigger the -2.42716126e-15
case.

Fix this as good as possible by choosing once between -5.9822653797615723e-120
and -2.42716126e-15, assigning it to re_val_oct_f, and using it everywhere
where those constants are used.

Tested on x86_64-linux.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
PR testsuite/33669
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33669

diff --git a/gdb/testsuite/gdb.base/long_long.exp b/gdb/testsuite/gdb.base/long_long.exp
index a28e07a64d1fe5786fa96bb7f9bd581abf797024..38d19346c064625d03a1dd0736d2474a06a4fff4 100644 (file)
--- a/gdb/testsuite/gdb.base/long_long.exp
+++ b/gdb/testsuite/gdb.base/long_long.exp
@@ -133,25 +133,11 @@ gdb_test_ptr "p/a val.oct" "" "" "0x77053977" "0xa72ee53977053977"
 gdb_test "p/c val.oct" "'w'"
 
 if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
-    # ARM FPA floating point numbers are not strictly little endian or big
-    # endian, but a hybrid.  They are in little endian format with the two
-    # words swapped in big endian format.
-    # EABI targets default to natural-endian VFP format.
-
-    if { ([istarget "arm*-*-*"]) \
-        && !([istarget "*-*-*eabi*"] || \
-             [istarget "*-*-mingw32ce*"] || \
-             [istarget "*-*-openbsd*"]) } then {
-       # assume the long long represents a floating point double in ARM format
-       gdb_test "p/f val.oct" "2.1386676354387559e\\+265"
-    } else {
-       # assume the long long represents a floating point double in little
-       # endian format
-       gdb_test "p/f val.oct" "-5.9822653797615723e-120"
-    }
+    set re_val_oct_f [string_to_regexp "-5.9822653797615723e-120"]
 } else {
-    gdb_test "p/f val.oct" "-2.42716126e-15"
+    set re_val_oct_f [string_to_regexp "-2.42716126e-15"]
 }
+gdb_test "p/f val.oct" $re_val_oct_f
 
 gdb_test_char "p/x *(char *)c" "0x1"
 gdb_test_char "p/d *(char *)c" "1"
@@ -208,11 +194,7 @@ gdb_test "x/o w" "0110642547"
 gdb_test "x/t w" "00000001001000110100010101100111"
 gdb_test_xptr "x/a" { b "" } { h "" } { w "0x1234567" } { g "0x123456789abcdef" }
 gdb_test "x/c b" "1 '.001'"
-if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
-    gdb_test "x/f &val.oct" "-5.9822653797615723e-120"
-} else {
-    gdb_test "x/f &val.oct" "-2.42716126e-15"
-}
+gdb_test "x/f &val.oct" $re_val_oct_f
 
 # Implicit Giant size (except for a, c, and f)
 
@@ -225,9 +207,9 @@ gdb_test "x/2t g" "0000000100100011010001010110011110001001101010111100110111101
 gdb_test_xptr "x/2a" { b "" } { h "" } { w "0x1234567.*0xa72ee539" } { g "0x123456789abcdef.*0xa72ee53977053977" }
 gdb_test "x/2c b" "1 '.001'.*-89 '.\[0-9\]*'"
 if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
-    gdb_test "x/2f &val.oct" "-5.9822653797615723e-120.*-5.9041889495880968e-100"
+    gdb_test "x/2f &val.oct" "$re_val_oct_f.*-5.9041889495880968e-100"
 } else {
-    gdb_test "x/2f &val.oct" "-2.42716126e-15"
+    gdb_test "x/2f &val.oct" "$re_val_oct_f"
 }
 
 # Explicit sizes, and two memory locations ...
@@ -266,7 +248,7 @@ gdb_test "x/2go g" "04432126361152746757.*01234567123456701234567"
 gdb_test "x/2gt g" "0000000100100011010001010110011110001001101010111100110111101111.*1010011100101110111001010011100101110111000001010011100101110111"
 gdb_test_ptr "x/2ga g" "" "" "0x89abcdef.*0x77053977" "0x123456789abcdef.*0xa72ee53977053977"
 gdb_test "x/2gc g" "-17 '.\[0-9\]*'.*119 'w'"
-gdb_test "x/2gf g" "3.5127005640885037e-303.*-5.9822653797615723e-120"
+gdb_test "x/2gf g" "3.5127005640885037e-303.*$re_val_oct_f"
 
 # Repeat behavior.
 gdb_test "x/2bx b" "0x01.*0xa7" "set up for repeat"