** Vincent Lefevre [2016-12-06 12:39:27 +0100]: > 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). Yes, that seems to be the case on x86_64 (64-bit) machine. > >> 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. I figured that out. I was confused at the beginning that C program produces file 16 bytes long, as well as FORTRAN program. I was expecting that both files would contain the same "number". I naively thought that as both FORTRAN and C programs were compiled by compilers from the one project --- GCC, then they should use, internally may be, the same code, or give the same output. I was wrong. >> $ hexdump bin-ldouble.dat >> 0000000 5555 5555 5555 5555 5555 5555 5555 3ffd >> 0000010 > > This is quadruple precision. Yes, wiki page suggests the same (still not sure why the order is opposite). > >> 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. Thank you for the link, I have read several wiki pages regarding the problem and seems to come to some (intermediate) conclusions. 1. It is possible to use 'long double' with quadruple precision in C if program will be compiled by GCC compiler with option '-mlong-double-128' (works in gcc 6.2.1). Also, I found out that Intel C++ compiler would give quadruple precision for 'long double' if one would use '_Quad' instead of 'long double' (unstandard type) and compile the program with options '/Qlong-double /Qoption,cpp,--extended_float_type'. 2. It is clear what to expect from FORTRAN code if one asks to use 16 bytes number (quad precision ,real(kind=16)). If compiler has support of quadruple precision it should give such "numbers". 3. On the other hand, C standard, AFAIK, (not sure about C++) don't specify how long in bytes must be float, double and long double (as well as 'standard' short, int and long) types. This is opposite to "standard" explicitly sized types: [u]int{8,16,32,64}_t. If there were "standard" floating point types, like 'float32' (4 bytes long), 'float64' (8 bytes) and 'float128' (16 bytes) I think there wouldn't be any misunderstandings. After some investigation, I would say, IMO, that situation with floating point calculations in C is a bit fuzzy, in contrast with FORTRAN. > -- > 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) --- WBR, Vladimir Lomov -- "We dedicated ourselves to a powerful idea -- organic law rather than naked power. There seems to be universal acceptance of that idea in the nation." -- Supreme Court Justice Potter Steart
