Why function printf does not support long double?

[yuriisig]

Why there is no print support long double?

Line of compilation: icl /O2 /Qlong-double /Qpc80 fp:extended test.c

[Marián__VooDooMan__M]

ICC uses under Windows Microsoft's CRT library, and Microsoft decided not to support long double. This topic was discussed here many times. I use long double extensively, but before C++'s "cout << ld_number" or "printf" and friends, you need to, sadly, cast it to double. I'm not happy with this situation as well :-(.

[yuriisig]

Thanks. I know it. My question for compiler writers. Why they do not do this support?

[JenniferJ]

I checked with our math lib team, the printf() does support "long double". did you use %Lf, %Lg, ... (L followed by any of f, F, e, E, g, G, a, A)

Jennifer 

[SergeyKostrov]

>>...the printf() does support "long double". did you use %Lf... The %Lf option works well ( I've been using it for a long time ), it is highly portable and supported by many C/C++ compilers.

[Bernard]

Jennifer J. (Intel) wrote:

I checked with our math lib team, the printf() does support "long double". did you use %Lf, %Lg, ... (L followed by any of f, F, e, E, g, G, a, A)

Jennifer 

Thanks Jennifer.

[Marián__VooDooMan__M]

Jennifer J. (Intel) wrote:

I checked with our math lib team, the printf() does support "long double". did you use %Lf, %Lg, ... (L followed by any of f, F, e, E, g, G, a, A)

Jennifer 

Is there any plan to support "long double" for MSVC 2012, x64 project build, /Qlong_double switch (i.e. 128-bit float) in stringstream's (and friends) in C++ (">>" and "<<" operators, EDIT: i.e. float-to-string and string-to-float conversions)? I am missing this feature so bad. Also, it would be nice if IDE debugger would be able to display content of 128-bit "long double" variable, but I can live with current status.

[SergeyKostrov]

>>Is there any plan to support "long double" for MSVC 2012, x64 project build, /Qlong_double switch (i.e. 128-bit float) in Intel has No influence on Microsoft in that matter and it is better to ask Microsoft C++ compiler team. >>stringstream's (and friends) in C++ (">>" and "<<" operators, EDIT: i.e. float-to-string and string-to-float conversions)? You could do it on your own. Please take a look at how C++ operator << for double implemented, then duplicate the code and add support for long double.

[TimP]

Microsoft historically has impeded support for long double, since the time (VS5?) when they introduced the ABI requirement that .exe must initialize 53-bit precision mode.  No doubt, they wanted to avoid the inconsistencies inherent in optimization of double in 64-bit precision mode.  In pre-release versions of X64 tools, they disallowed all use of x87 instructions, and their X64 compilers never supported x87.  I wouldn't start holding my breath expecting a change.

[SergeyKostrov]

>>Microsoft historically has impeded support for long double, since the time (VS5?) when they introduced the ABI requirement >>that .exe must initialize 53-bit precision mode. I could easily verify it some time later ( I have VC++ v5.x installed ) but it looks like the problem is significantly older and originated in a Microsoft Quick C of some version even before Visual C++ v1.5 ( some time before 1995 ) & Visual C++ 2.0 ( 1995 ) were released.

[Marián__VooDooMan__M]

Sergey Kostrov wrote:

>>Is there any plan to support "long double" for MSVC 2012, x64 project build, /Qlong_double switch (i.e. 128-bit float) in

Intel has No influence on Microsoft in that matter and it is better to ask Microsoft C++ compiler team.

Indeed. But Intel has option in MSVC IDE "Use Intel Optimized Headers" (tough I don't know what it does, I tend to enable it all the time, just for optimization's sake, and I will check the documentation later). Maybe Intel could provide their own headers for this option as (parts of/full?) STL to implement mentioned operators, or conversions.

Sergey Kostrov wrote:

>>stringstream's (and friends) in C++ (">>" and "<<" operators, EDIT: i.e. float-to-string and string-to-float conversions)?

You could do it on your own. Please take a look at how C++ operator << for double implemented, then duplicate the code and add support for long double.

Yes, indeed I will do, but I'm afraid it would be a copyright infrigement. I better steal code from STLport (after investigation whether it is suitable).

[SergeyKostrov]

>>... I'm afraid it would be a copyright infrigement... It is a good comment. Thanks. At the same time please take a look at Copyright notes from Hewlett-Packard Company ( I've taken it from STL v3.3 ): ... * Copyright (c) 1994 * Hewlett-Packard Company * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Hewlett-Packard Company makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. * * Copyright (c) 1996-1998 * Silicon Graphics Computer Systems, Inc. * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Silicon Graphics makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. ...

[SergeyKostrov]

This is a short follow up with some technical details. >>>>Microsoft historically has impeded support for long double, since the time (VS5?) when they introduced the ABI requirement >>>>that .exe must initialize 53-bit precision mode. >> >>I could easily verify it some time later ( I have VC++ v5.x installed )... This is a piece of code from math.h header file ( released in 1996 ): ... /* Macros defining long double functions to be their double counterparts * (long double is synonymous with double in this implementation). */ #ifndef __cplusplus ... #define ceill(x) ( ( long double )ceil( ( double )(x) ) ) ... #define expl(x) ( ( long double )exp( ( double )(x) ) ) #define fabsl(x) ( ( long double )fabs( ( double )(x) ) ) ... As you can see there is a "forced" cast to double for all input arguments of these CRT-functions.

[SergeyKostrov]

>>..."Use Intel Optimized Headers" (tough I don't know what it does, I tend to enable it all the time, just for optimization's sake, >>and I will check the documentation later). Maybe Intel could provide their own headers for this option... Intel provides these headers and take a look at [ IccInstallDir ]\Composer XE\Compiler\Include folder.

[TimP]

Sergey Kostrov wrote:

This is a short follow up with some technical details.

>>>>Microsoft historically has impeded support for long double, since the time (VS5?) when they introduced the ABI requirement
>>>>that .exe must initialize 53-bit precision mode.
>>
>>I could easily verify it some time later ( I have VC++ v5.x installed )...

This is a piece of code from math.h header file ( released in 1996 ):
...
/* Macros defining long double functions to be their double counterparts
* (long double is synonymous with double in this implementation).
*/

#ifndef __cplusplus
...
#define ceill(x) ( ( long double )ceil( ( double )(x) ) )
...
#define expl(x) ( ( long double )exp( ( double )(x) ) )
#define fabsl(x) ( ( long double )fabs( ( double )(x) ) )
...

As you can see there is a "forced" cast to double for all input arguments of these CRT-functions.

If you were running in x87 64-bit precision mode, this could make the long double and double versions of ceil() and fabs() practically interchangeable with in-lining.  The effect on exp() would be more difficult to guess, but I wouldn't count on protection of accuracy for values outside double range.

The "Intel optimized headers" make some substitutions of IPP library functions.  As Sergey said, you should view the headers to see if this applies to the functions you use on your target platform.  Normally, this will introduce dependency on IPP .dll.

[Judith_W_Intel]

If we provided our own version of the C++ standard library it would be nearly impossible to guarantee link compatible object files (all of the class layout, virtual tables, etc. for all the standard library classes would have to magically be the same). We guarantee that if a user compiles a source file with the Microsoft compiler and our Windows compiler that they are interoperable.

Judy