On 2016-12-03 22:10:52 +0800, Vladimir Lomov wrote: > I faced strange problem with long double (C) in comparison with fortran > (gfortran) on my system: > Archlinux x86_64, gcc 6.2.1 20160830. So, in C, long double = x86 extended precision (80 bits + padding). > I prepared two small programs on C and Fortran (see attached files): > c-double-ldouble.c, gfortran-real-quad.f95. [...] > and in accordance with > https://en.wikipedia.org/wiki/Double-precision_floating-point_format > (except the order, but I suppose this is expected), but for long double > and real(kind=16) and different > > $ hexdump bin-ldouble.bin > 0000000 aaab aaaa aaaa aaaa 3ffd 99fb 7ffe 0000 > 0000010 The first five 16-bit words correspond to the value on 80 bits. The other three 16-bit words are padding and contain garbage. > $ hexdump bin-ldouble.dat > 0000000 5555 5555 5555 5555 5555 5555 5555 3ffd > 0000010 This is quadruple precision. > I suppose that hexdump for fortran case is correct, according to > https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format > so result of long double is wrong, besides it depends on options passed > to compiler. No, this is just a different format. See: https://en.wikipedia.org/wiki/Long_double for the various formats depending on the platform. -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
