David Friedman wrote:
> GDC now supports 64-bit targets! A new x86_64 Linux binary is
> available and the MacOS X binary supports x86_64 and ppc64.
>
> http://sourceforge.net/project/showfiles.php?group_id=154306
>
> Changes:
> * Added support for 64-bit targets
> * Added multilib support
> * Updated to DMD 1.007
> * Fixed Bugzilla 984, 1013
super awesome! thanks david!
The annoying thing about this for me is as soon as I see this announcement, I want to write layman -S and get the latest ebuild of gdc. It seems like Anders and I are the ones who generally update bugzilla with the latest gdc release (coming soon, btw). Who would I email to get commit access to add gdc to the dlang overlay for layman? I have no problems updating these as soon as the new versions of dmd/gdc come out either -- as I notice layman is usually a few days behind.
kenny

Anders F Björklund wrote:
>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>>> available and the MacOS X binary supports x86_64 and ppc64.
>>
>> Excellent news! I'll try it on ppc64 Linux too (Fedora Core)
>
> Except for some strange (temporary?) build error with soft-float,
> it built just fine for powerpc64-unknown-linux-gnu (with FC5/PPC*)
That reminds me. Is it really a good idea to map the GCC/PPC "long
double" to "real" in D? I know this has come up before:
http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
and the data type seems like an aberration. Here is some more info:
http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00499.html
And from the ELF ABI:
This "Extended precision" differs from the IEEE 754 Standard
in the following ways:
* The software support is restricted to round-to-nearest
mode. Programs that use extended precision must ensure
that this rounding mode is in effect when
extended-precision calculations are performed.
* Does not fully support the IEEE special numbers NaN and
INF. These values are encoded in the high-order double
value only. The low-order value is not significant.
* Does not support the IEEE status flags for overflow,
underflow, and other conditions. These flag have no
meaning in this format.
I can't claim to have the maths background of some folks here, but this
suggests to me that this 128-bit representation isn't truly IEEE-754
compliant and therefore probably shouldn't be a default data type in D?
Sean

Sean Kelly wrote:
> Anders F Björklund wrote:
>>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>>>> available and the MacOS X binary supports x86_64 and ppc64.
>>>
>>> Excellent news! I'll try it on ppc64 Linux too (Fedora Core)
>>
>> Except for some strange (temporary?) build error with soft-float,
>> it built just fine for powerpc64-unknown-linux-gnu (with FC5/PPC*)
>
> That reminds me. Is it really a good idea to map the GCC/PPC "long
> double" to "real" in D? I know this has come up before:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
>
> and the data type seems like an aberration. Here is some more info:
>
[snip references]
>
> I can't claim to have the maths background of some folks here, but this
> suggests to me that this 128-bit representation isn't truly IEEE-754
> compliant and therefore probably shouldn't be a default data type in D?
From reading that I get the impression that this "long double" is
actually two doubles that software pretends to be a more-precise single
number. If that's correct, I think this may indeed be a bad idea.
I'm also pretty sure it's in fact against the spec:
http://www.digitalmars.com/d/type.html describes 'real' as the "largest
hardware implemented floating point size". And this data type seems to
be software-implemented rather than hardware-implemented...

Sean Kelly wrote:
> That reminds me. Is it really a good idea to map the GCC/PPC "long
> double" to "real" in D? I know this has come up before:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
No, it's not a good idea to do this on the PowerPC, if the
-mlong-double-128 option is used. (i.e. instead of 64 bits)
I haven't checked what the default ABI is on later versions,
but I'm afraid that "double double" might be the default now...
Staying clear of the "real" type on non-X86 sounds like an idea.
> I can't claim to have the maths background of some folks here, but this
> suggests to me that this 128-bit representation isn't truly IEEE-754
> compliant and therefore probably shouldn't be a default data type in D?
The D definition of real as the "largest hardware supported type"
indicates that it should be defined as double on PowerPC (32/64).
At least until there is some kind of new model that does 128-bit
floating point in hardware, instead of faking it with two 64-bit.
I think that things would have been better with an 80-bit D type.
--anders

Sean Kelly wrote:
> Anders F Björklund wrote:
>>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>>>> available and the MacOS X binary supports x86_64 and ppc64.
>>>
>>> Excellent news! I'll try it on ppc64 Linux too (Fedora Core)
>>
>> Except for some strange (temporary?) build error with soft-float,
>> it built just fine for powerpc64-unknown-linux-gnu (with FC5/PPC*)
>
> That reminds me. Is it really a good idea to map the GCC/PPC "long
> double" to "real" in D? I know this has come up before:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
>
> and the data type seems like an aberration. Here is some more info:
>
> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00499.html
>
> And from the ELF ABI:
>
> This "Extended precision" differs from the IEEE 754 Standard
> in the following ways:
>
> * The software support is restricted to round-to-nearest
> mode. Programs that use extended precision must ensure
> that this rounding mode is in effect when
> extended-precision calculations are performed.
> * Does not fully support the IEEE special numbers NaN and
> INF. These values are encoded in the high-order double
> value only. The low-order value is not significant.
> * Does not support the IEEE status flags for overflow,
> underflow, and other conditions. These flag have no
> meaning in this format.
>
> I can't claim to have the maths background of some folks here, but this
> suggests to me that this 128-bit representation isn't truly IEEE-754
> compliant and therefore probably shouldn't be a default data type in D?
>
>
> Sean
Sean, thanks for posting that; I was about to do the same.
The IEEE-754 standard is pretty clear on the fact that these
double-doubles are *NOT* IEEE-754 compliant. (In fact, storing the
significand in two parts is already enough to be non-compliant).
Allowing this as a 'real' is a bit of a disaster; for example, it means
that IEEE status flags and precision modes cannot be used portably on
any platform, and it makes support for even basic mathematical functions
extremely difficult.
The stupid thing is, that the underlying double-double type exists on
all platforms! There would be great benefit someday in supporting
double-doubles in the compiler -- just not as a 'real'.
IMHO, 'real' should map to 'double' on PPC.

Lionello Lunesu wrote:
> David Friedman wrote:
>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>> available and the MacOS X binary supports x86_64 and ppc64.
>>
>> http://sourceforge.net/project/showfiles.php?group_id=154306
>>
>> Changes:
>> * Added support for 64-bit targets
>> * Added multilib support
>> * Updated to DMD 1.007
>> * Fixed Bugzilla 984, 1013
>
> Ah, cool!
>
> I want to try this under Windows x64, but I have no idea how to install
> GDC. The installer on sf.net are only "partial", what else do I need?
> MSYS? Tried that once, didn't work.
>
> L.
OK, so it was actually easier to install Ubuntu x64 and GDC. This took
me less time than trying to get GDC (even x86) to work under vista/XP.
L.