LDBL_MAX -1.#QNAN0e+000 with MinGW?

[jacob navia]

Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.

The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.

 

[CBFalconer]

jacob navia scrisse:
.... snip ...


wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float

if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)

Much as it pains me to defend Microsoft, this is not about '80 bit'
floats (which are not a defined type) but about 'long double',
which is defined. The definition allows Microsofts
implementation. It does not allow the Ming implementation.

 

[santosh]

The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.

Okay, and BTW, does lcc-win make use of the XMM registers to speed up
calculations (under appropriate code gen. switches of course).

 

[jacob navia]

Okay, and BTW, does lcc-win make use of the XMM registers to speed up
calculations (under appropriate code gen. switches of course).

Only in the 64 bits versions

 

[RoS]

In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:

Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!

excuse me i have read wrong
but LDBL_MAX etc will be different

 

[James Kuyper]

In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:

excuse me i have read wrong
but LDBL_MAX etc will be different

Yes; a system which uses the same representation for double and long
double will have the same values for DBL_MAX and LDBL_MAX; that doesn't
make it in any way non-conforming.

 

[Barry Schwarz]

In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:


wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float

if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)

Since the vast majority of floating point numbers are approximations,
whether an 80 bit approximation can be represented with a 64 bit
approximation depends more on the number of bits in the exponent than
the number of bits in the mantissa.


Remove del for email

 

[David Thompson]

gcc happens support the full extended precision 80-bit format of the
Intel math coprocessor/FPU for long double. But Microsoft made a
marketing decision a long, long time ago, and decided not to.

Specifically:

"With the 16-bit Microsoft C/C++ compilers, long doubles are stored as
80- bit (10-byte) data types. Under Windows NT, in order to be
compatible with other non-Intel floating point implementations, the
80-bit long double format is aliased to the 64-bit (8-byte) double
format."

You can read the entire sad article on Microsoft's site, in their own
words here:

http://support.microsoft.com/kb/129209

The wording is gibberish, by the way, the 8-bit format is not
"aliased", whatever that means, to 64-bits. It merely means when you
define an object of long double, they use the same 64-bit format that
they use for ordinary double.

I don't think that's gibberish; I think 'aliased' is just a slightly
clumsy way of saying that long double is another 'name' for double (or
more precisely the type named by double), in their implementations.

Which I agree with you and others is legal, but less useful than using
it to provide the available 80-bit type.

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Tim Prince]

I don't think that's gibberish; I think 'aliased' is just a slightly
clumsy way of saying that long double is another 'name' for double (or
more precisely the type named by double), in their implementations.

Which I agree with you and others is legal, but less useful than using
it to provide the available 80-bit type.

We appeared to disagree on what to call the situation where an
implementation supporting 80-bit long double rides on a library which
supports only 53-bit precision mode.