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

[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