March 06, 2007
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

hurray! Now I can finaly get all I wanted(muaha). :D


March 07, 2007
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.

I don't think there is a 64-bit MinGW target for GCC yet.  GDC may 64-bit Cygwin might work.

David
March 07, 2007
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

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.

David
March 07, 2007
Neal Becker 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
> 
> 
> Thanks!
> 
> Any suggested installation procedure on linux?
> 
> Extracting the linux 64-bit binary gives:
> 
> dmd/
>   bin/
>   include/
>   lib/
>   lib64/
>   libexec/
>   man/
>   share/
> 
> The obvious choice of
> mv dmd/bin/* /usr/bin
> mv dmd/include/* /usr/include
> mv dmd/lib/* /usr/lib <<< ooops!
> 
> That last one will cause conflicts.  So what's the recommended procedure?

This should have already been in the README...

The best way to use the binary package is to extract wherever you want (/opt, $HOME/sw, etc...) and add the 'gdc/bin' directory to your PATH.

Trying to copy the files into /usr is a bad idea unless you know that the GCC version and configuration is exactly the same.

David

David


March 07, 2007

David Friedman wrote:
> 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
> 
> 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.
> 
> David

I might be off-base, but couldn't you do something like this?

> version( GDC )
>     pragma(gdc_enable, gdc_longdouble);
>
> // ...
>
> extern(C) gdc_longdouble foo(gdc_longdouble);

Yes, you'd be adding a new type, but at least it's hidden behind a pragma.  Interfacing with C code is fairly important to D, but I'd hate to have fp code that works fine under DMD and then mysteriously breaks with gdc--I think compatibility with other D implementations should come before interfacing with C.

Just my AU$0.02.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
March 07, 2007
David Friedman 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?


Sean
March 07, 2007
On Tue, 06 Mar 2007 01:16:07 -0500, 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


I just realized that gdc still hasn't arrived at 1.0 yet even though the stated criteria for a gdc 1.0 was 64-bit support. :)

I guess gdc will remain pre-1.0 for awhile to see if any 64-bit bugs surface?

-JJR
March 07, 2007
On Tue, 06 Mar 2007 22:13:42 -0500, David Friedman wrote:

> This should have already been in the README...
> 
> The best way to use the binary package is to extract wherever you want (/opt, $HOME/sw, etc...) and add the 'gdc/bin' directory to your PATH.
> 
> Trying to copy the files into /usr is a bad idea unless you know that the GCC version and configuration is exactly the same.
> 
> David
> 

I agree that using the home directory is the best way. I've been doing it this way, and it works very well.

It's also quite easy to append the ~/gdc/bin path inside the bash startup script for the console (typically '.bashrc' or '.bash_profile').  That way, it becomes really simple to run the gdc executable from the commandline. Add 'rebuild' to the mix and compiling projects with gdc becomes a snap. :)

-JJR
March 07, 2007
John Reimer wrote:
> On Tue, 06 Mar 2007 01:16:07 -0500, 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
> 
> 
> I just realized that gdc still hasn't arrived at 1.0 yet even though the
> stated criteria for a gdc 1.0 was 64-bit support. :)
> 
> I guess gdc will remain pre-1.0 for awhile to see if any 64-bit bugs
> surface?
> 
> -JJR

This has come up before. :)

1.0 must have 64 bit support, but 64 bit support doesn't imply 1.0

You'd have to dig into the archives to find the post from David to see if it clarified what other requirements he had in mind before a 1.0 release.

Later,
Brad
March 07, 2007
David Friedman wrote:

>> That last one will cause conflicts.  So what's the recommended procedure?
> 
> This should have already been in the README...
> 
> The best way to use the binary package is to extract wherever you want (/opt, $HOME/sw, etc...) and add the 'gdc/bin' directory to your PATH.
> 
> Trying to copy the files into /usr is a bad idea unless you know that the GCC version and configuration is exactly the same.

I'll be posting RPMs, as usual. They do install in /usr by default
(%{prefix} really) but usually don't conflict since GDC is built
for i686-pc-linux-gnu and the usual one is i386-redhat-linux...

Currently there is just a binary/nosource wrapper of your tarballs:
http://gdcgnu.sourceforge.net/gdc-bin.spec (this is an RPM specfile)
There will probably be a real source package later, that builds it.

--anders