Printing REAL 10 values with the gcc

[Gunther]

I've started a thread in the old UK forum which deals with printing REAL10 (long double) numbers. There isn't a problem with the gcc under the Linux operating system, but under Windows the compiler output is only garbage. My suspicion was that this has to do with the windows libc, because the gcc must use it and the MS compilers don't support this data type.

But that seems not quiet right: surprisingly enough, with g++ (the C++ compiler of the gnu compiler collection) isn't such a problem. It handles REAL10 values correctly. I could figure out that during studying some C++ sources in Geneva. I won't publish that sources, but I've written a small test program which illustrates the point.

The program is tested under Windows 7 and Windows 8 (64 bit).

Gunther

[Gunther]

Added is the C source LongC64.zip. For more explanation, please check also that thread. Here is the output:

Code Select Expand



Layout of data types:
=====================

Long Double (REAL10)    = 16 Bytes
Double (REAL8)          =  8 Bytes
Float (REAL4)           =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = 3.1415926535897932385
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.141593

Press any key to continue ...


Gunther

[TimoVJL]

Sure, but i don't use gcc, nor it's extended features

[Gunther]

Timo,

Sure, but i don't use gcc, nor it's extended features

that's not my point. The gcc (for Win) is a native windows tool and it's possible to print via the libc REAL10 values (with a bit command line magic) with the full range of digits. Try this with
another windows compiler.

Gunther 

[TimoVJL]

-m96bit-long-double
-m128bit-long-double

    These switches control the size of long double type. The x86-32 application binary interface specifies the size to be 96 bits, so -m96bit-long-double is the default in 32-bit mode.

    Modern architectures (Pentium and newer) prefer long double to be aligned to an 8- or 16-byte boundary. In arrays or structures conforming to the ABI, this is not possible. So specifying -m128bit-long-double aligns long double to a 16-byte boundary by padding the long double with an additional 32-bit zero.

    In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that long double is aligned on 16-byte boundary.

    Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double.

    Warning: if you override the default value for your target ABI, this changes the size of structures and arrays containing long double variables, as well as modifying the function calling convention for functions taking long double. Hence they are not binary-compatible with code compiled without that switch.
-mlong-double-64
-mlong-double-80
-mlong-double-128

    These switches control the size of long double type. A size of 64 bits makes the long double type equivalent to the double type. This is the default for 32-bit Bionic C library. A size of 128 bits makes the long double type equivalent to the __float128 type. This is the default for 64-bit Bionic C library.

    Warning: if you override the default value for your target ABI, this changes the size of structures and arrays containing long double variables, as well as modifying the function calling convention for functions taking long double. Hence they are not binary-compatible with code compiled without that switch.

about long double
https://retrocomputing.stackexchange.com/questions/9751/did-any-compiler-fully-use-intel-x87-80-bit-floating-point

[jj2007]

The gcc (for Win) is a native windows tool

You mean native in the sense of "it works on Windows", not as in "it comes installed with Windows", right?

You could link in MasmBasic.lib; Raymond's FpuLib must have a routine, too, and even the Masm32 SDK might have one. Why Gcc?

Code Select Expand

include \masm32\MasmBasic\MasmBasic.inc
  Init
  fldpi
  fldl2e
  fldl2t
  fldlg2
  fldln2
  deb 4, "FPU Constants", ST(4), ST(3), ST(2), ST(1), ST(0)
EndOfCode

Output:

Code Select Expand

FPU Constants
ST(4)           3.141592653589793238
ST(3)           1.442695040888963407
ST(2)           3.321928094887362348
ST(1)           0.3010299956639811952
ST(0)           0.6931471805599453094

[jack]

you can print long-double values by either using -D__USE_MINGW_ANSI_STDIO=1 on the compile command or by including #define __USE_MINGW_ANSI_STDIO 1 in your source
in recent mingw-gcc that may not be necessary, have not tested it though

[Gunther]

Jack,

you can print long-double values by either using -D__USE_MINGW_ANSI_STDIO=1 on the compile command or by including #define __USE_MINGW_ANSI_STDIO 1 in your source
in recent mingw-gcc that may not be necessary, have not tested it though

Right. That's done inside the source of  LongC64.zip. This is from 2013. That was my point.

Jochen,

The gcc (for Win) is a native windows tool

You mean native in the sense of "it works on Windows", not as in "it comes installed with Windows", right?

yes, of course. I think we've beaten that to death in several threads a few years ago. And we can print out with the full digit accuracy of REAL10. It's not only a bit cosmetic.

Gunther

[TimoVJL]

As gcc, icc, clang have a long double, those can be used for greater accuracy for calculations.
Sadly clang don't have own runtime library.

[Gunther]

Timo,

Sadly clang don't have own runtime library.

do you have any experiences with clang? Some people tell miraculous things about it.

Gunther