March 06, 2007
Thank You, David - Your work is _GREATLY_ apriciated!
March 06, 2007
Move to:
/usr/local/lib
/usr/local/include
/usr/local/bin

My rule of thumb is that /usr/ is for your distros packagemanager and /usr/local are for all that you yourself install. Keeps evertyhing neat and tidy.

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?

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

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
March 06, 2007
David Friedman escribió:
> 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

Great! Thanks!

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

Great work!


Sean
March 06, 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:
> 
[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...
March 06, 2007
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
March 06, 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

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

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.