sizeof(long double) vs. std::numeric_limits and x86-64 vs x86

sizeof(long double) vs. std::numeric_limits and x86-64 vs x86

[Michael Veksler]

Hello,

I wanted to check how many bits long double takes. So I checked 
sizeof(long double) which, naturally, may account for padding. On x86-64 
it takes 16 bytes and only 12 on x86, a difference of 4 bytes. This 
supported my hope that on x86-64 we would have "long double"= |__float128|.


But this difference does not exist in std::numeric_limits<long double>. 
Does it really mean that only the
padding is different between the architectures, but the type is still 
the same?

If "long double" != |__float128|, then is there any chance to have a 
correct definition of std::numeric_limits<__float128> in the near 
future? If not, where can I find macro names such as __LDBL_MANT_DIG__ 
for __float128?
Running
gcc -g -E -dM t.cpp | grep MANT_DIG__
gives only

    #define __FLT_MANT_DIG__ 24
    #define __DEC64_MANT_DIG__ 16
    #define __LDBL_MANT_DIG__ 64
    #define __DBL_MANT_DIG__ 53
    #define __DEC32_MANT_DIG__ 7
    #define __DEC128_MANT_DIG__ 34

no mention of anything like FLT128

Thanks

-- 
   Michael

Re: sizeof(long double) vs. std::numeric_limits and x86-64 vs x86

[Ian Lance Taylor]

Michael Veksler <mveksler@tx.technion.ac.il> writes:

> I wanted to check how many bits long double takes. So I checked
> sizeof(long double) which, naturally, may account for padding. On
> x86-64 it takes 16 bytes and only 12 on x86, a difference of 4
> bytes. This supported my hope that on x86-64 we would have "long
> double"= |__float128|.

Alas, no.  On x86_64 long double is an 80-bit floating point number,
just as on 32-bit x86.  The size is 16 bytes because the x86_64 prefers
to align large values to 8-byte boundaries.

gcc works this way because the 80-bit floating point format is supported
directly in hardware, unlike the 128-bit format.

Ian

Re: sizeof(long double) vs. std::numeric_limits and x86-64 vs x86

[Michael Veksler]

On 09/27/2011 01:46 AM, Ian Lance Taylor wrote:
> Alas, no. On x86_64 long double is an 80-bit floating point number,
> just as on 32-bit x86.  The size is 16 bytes because the x86_64 prefers
> to align large values to 8-byte boundaries.
>
> gcc works this way because the 80-bit floating point format is supported
> directly in hardware, unlike the 128-bit format.
>
>

I suspected that this is the case, but hoped for the better.

Thanks

--

   Michael

Re: sizeof(long double) vs. std::numeric_limits and x86-64 vs x86

[Toon Moene]

On 09/27/2011 12:46 AM, Ian Lance Taylor wrote:

> Michael Veksler<mveksler@tx.technion.ac.il>  writes:
>
>> I wanted to check how many bits long double takes. So I checked
>> sizeof(long double) which, naturally, may account for padding. On
>> x86-64 it takes 16 bytes and only 12 on x86, a difference of 4
>> bytes. This supported my hope that on x86-64 we would have "long
>> double"= |__float128|.
>
> Alas, no.  On x86_64 long double is an 80-bit floating point number,
> just as on 32-bit x86.  The size is 16 bytes because the x86_64 prefers
> to align large values to 8-byte boundaries.
>
> gcc works this way because the 80-bit floating point format is supported
> directly in hardware, unlike the 128-bit format.

But if you really long for 16 byte floating point computations, you 
could always switch to Fortran:

$ cat a.f
       REAL*16 A
       CHARACTER*80 :: LINE = ' 394728372973498274982794792.342987E3798'
       READ(LINE, *) A
       PRINT*,A
       END
$ gfortran a.f
$ ./a.out
   3.94728372973498274982794792342987006E+3824
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4' 
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr 
--program-suffix=-4.6 --enable-shared --enable-multiarch 
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.6 
--libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin 
--enable-objc-gc --with-arch-32=i586 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4)

:-)

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news