icc for linux should treat long double the same as the corresponding gcc.  Without icc-specific not-fully-supported options, that's 80-bit, plus padding depending on whether it's ia32 or intel64 compilation mode.

The conversion between float or double and long double is efficient only in -mia32 mode (available only in the ia32 compiler), which excludes auto-vectorization.

icc linux practice for long double will not be the same as ICL for Windows

As I mentioned in another thread, icc for intel64 is consistent with the gcc -m64 scheme of padding 80-bit long double type out to 128 bits.  It's an IEEE 80-bit extended, as long as you stick with documented options.  You should be able to infer this from <float.h>.

Yes, 80-bit long double is implemented by x87 instructions, hence may be slower when combined with double or float implemented in SSE2 than when everything is done by 32-bit compiler in non-SSE mode.  I don't know of any plan to implement full C support for 128-bit IEEE format, although evidently ifort has support libraries.  Neither type of long double works with vectorization, so there would not necessarily be any advantage for using icc over some other compiler supporting the long double data formats.

>>>I see ... Basically even for Intel64 target environmnet, long doubles are 80-bit extended padded to 128 bits? This brings up anoter Q:  to use the 80-bit extended one has to use x87 instructions as SSE do not support anything > double, correct? Or is some emulation done by S/W?>>>

As Tim said SIMD vector unit does not support 80-bit long double primitive type,so you are left with the option to use x87 FPU.If you are interested in speed of execution and less in precision I would advise you to use SSE2/3/4 instructions.

Hi Michael and I'm sorry that I "joined the party" a little bit late...

>>...
>>I am trying to determine if the IEEE extended presicion (80 bits) and quad precision (128 bits) formats are
>>supported in versions 12.1 or 13 of the C compiler.
>>...
>>I have been going over the manual but the only relevant information I ran into was one example using long double where the
>>variable is called 80bit...
>>...

In case of an 80-bit expression You're mixing two different things. Let's say there is some C/C++ compiler that fully supports the long double and 10-bytes allocated for a variable when it is declared, like:

...
long double ldVariable = 0.0L;
...

If a developer checks a size of long double type, like:

...
printf( "Number of bytes allocated: %d", sizeof( long double ) );
...

A result will be 10 bytes, that is 80 bits. However, a precision of a floating-point data type is a different thing and in that case it could be 64-bits, or 53-bits, or 24-bits, and it depends on how a Floating Point Unit ( FPU ) is initialized by default.

For many modern and legacy C/C++ compilers a default precision for the double-precision data type is 53-bits.

Maybe this is nit-picking, but the hardware default for x87 is full 64-bit precision.  64-bit Windows sets it to 53-bit precision before handing over control to a .exe; 53-bit Windows expects the .exe to initialize 53-bit precision.  The net result is that if you want 64-bit precision, you must set it yourself.  The ICL option /Qpc80 is an option which should do that.

Intel compilers for linux apparently set 53-bit precision (default to -pc64), but this is at variance with the practice of other compilers. One of the stranger situations would be with gcc on Windows, where a 32-bit mode gcc program would start out in 64-bit precision mode if running on 32-bit Windows, but 53-bit precision if running on Windows X64.  I don't know whether this may control the effective mode of gcc long double.

>>>A result will be 10 bytes, that is 80 bits. However, a precision of a floating-point data type is a different thing and in that case it could be 64-bits, or 53-bits, or 24-bits, and it depends on how a Floating Point Unit ( FPU ) is initialized by default.>>>

In case of IEEE 754-2008 128-bit quadruple precision binary number will have 112-bits of precision.

Michael, Let me know if you need a C/C++ example on how a precision of floating-point data types could be controlled.