GDC release 0.23

[Anders F Björklund]

Sean Kelly wrote:

>> The double+double type has caused me no end of trouble, but I think it 
>> is important to maintain interoperability with C.  If I make the D 
>> 'real' implementation IEEE double, there would be no way interact with 
>> C code that uses 'long double'.  I could add another floating point 
>> type for this purpose, but that would diverge from the D spec more 
>> than what I have now.
> 
> Yeah that doesn't sound like a very attractive option.  Some of the 
> later replies in the Darwin thread mention a compiler switch:
> 
> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00471.html
> 
> Is that a possibility?  Or did that switch not make it into an actual 
> release?

There are two switches: -mlong-double-64 and -mlong-double-128,
just that the second one ("double-double") is now the default...

So if you changed the meaning of "long double" back to the old one
(i.e. same as "double"), it wouldn't be compatible with C/C++ ABI ?


This is similar to the -m96bit-long-double and -m128bit-long-double
for Intel, but those just change the padding (not the 80-bit format)

But on the X86_64 architecture, a "long double" is now padded to 16
bytes instead of the previous 12 bytes (the actual data is 10 bytes)


These were all known problems with adding "real" as a built-in, though.
In all the D specs I've seen, it's pretty much #defined to long double.

Such as http://www.digitalmars.com/d/htod.html
http://www.digitalmars.com/d/interfaceToC.html

Might as well keep the real <-> long double one-to-one mapping, and
recommend *not* using real/ireal/creal types for any portable code ?

--anders