[Bug testsuite/29816] [gdb/testsuite, powerpc64le] FAIL: gdb.ada/float-bits.exp: print 16llf#4000921fb54442d18469898cc51701b8#

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29816

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Carl E Love from comment #7)
> I tried the fix on Power 9 and Power 10.  I see the same results with and
> without the patch. 
> 
> make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.ada/float-bits.exp '
> 
> The contents of gdb/testsuite/gdb.log:
> 
> print val_double^M
> $8 = -2.0e-19^M
> (gdb) PASS: gdb.ada/float-bits.exp: print val_double after assignment
> ptype long_long_float^M
> type = <8-byte float>^M
> (gdb) ptype 16llf#0#^M
> type = <16-byte float>^M
> (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M

Is this a sign of the patch not being applied, or of the patch not working?

The patch attempts to print a different hex string here.

> $9 = <invalid float value>^M
> (gdb) FAIL: gdb.ada/float-bits.exp: print
> 16llf#4000921fb54442d18469898cc51701b8#
> print $foo:=16llf#4000921fb54442d18469898cc51701b8#^M
> $10 = <invalid float value>^M
> (gdb) FAIL: gdb.ada/float-bits.exp: print
> $foo:=16llf#4000921fb54442d18469898cc51701b8#
> print $foo^M
> $11 = <invalid float value>^M
> (gdb) FAIL: gdb.ada/float-bits.exp: print internal long double variable
> after assignment
> testcase
> /home/carll/GDB/build-current/gdb/testsuite/../../../binutils-gdb-current/
> gdb/testsuite/gdb.ada/float-bits.exp c\
> ompleted in 0 seconds
> 
>                 === gdb Summary ===
> 
> # of expected passes            9
> # of unexpected failures        3
> 
> 
> 
> You mentioned OBS, what is that? Perhaps there is something different in our
> environments??

It's Open Build Service, specifically the place where I maintain a gdb package
for openSUSE/SLE ( https://build.opensuse.org/package/show/devel:gcc/gdb ).

But I debugged the test-case and wrote the fix outside of OBS.

A possibility for the FAILs with the patch that you mentioned, is that it's the
effect of having a different long double format.

The compiler I'm using is gcc 7.5.0, with the long double format defaulting to
--with-long-double-format=ibm.

But well, there could also be endian issues, I'm using powerpc64le.

The way I produced the hex string is by compiling:
...
long double a = 5.0e+25L;

int
main (void)
{
  return 0;
}
...
and in gdb doing "p /x a".

So, which hex string are you seeing when you do that, and which long double
format are you using?

-- 
You are receiving this mail because:
You are on the CC list for the bug.