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

[Ian Lance Taylor]

Post by Michael Veksler
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

[Michael Veksler]

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

[Toon Moene]

Post by Ian Lance Taylor

Post by Michael Veksler
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)

:-)