feature or a bug with long double (quad-precision) in gcc (6.2.1)

[Vladimir Lomov]

** 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@vinc17.net> - 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