www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.068 and 2.053 release

reply Walter Bright <newshound2 digitalmars.com> writes:
Thanks for everyone's hard work on this release!

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.067.zip

Now includes FreeBSD:

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.052.zip
May 13 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/13/11 4:27 PM, Walter Bright wrote:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

Repeated line: Added 64 bit tools to Linux In a way I do agree it deserves more than one line :o). Andrei
May 13 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
133 bytes? Something went wrong with that ftp for DMD2.
May 13 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm referring to http://ftp.digitalmars.com/dmd.2.053.zip. You've
posted the wrong links in your post btw.
May 13 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Thanks for everyone's hard work on this release!
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip
 Now includes FreeBSD:
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

Great release! (I know from testing the betas.) Two issues: The links are for previous releases and the docs for std.parallelism and std.net.isemail aren't on the website.
May 13 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2011 3:13 PM, dsimcha wrote:
 Great release!  (I know from testing the betas.)  Two issues:  The links are
for
 previous releases and the docs for std.parallelism and std.net.isemail aren't
on
 the website.

Up now.
May 13 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Thanks for everyone's hard work on this release!
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip
 Now includes FreeBSD:
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

Oh, one more question I've been meaning to ask for a while: Other than ridiculous corner cases (like needing more than 2 GB RAM for CTFE or not having 32-bit libs installed) is there any good reason to prefer either the 64-bit or 32-bit binary on a 64-bit system?
May 13 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 
 Thanks for everyone's hard work on this release!
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip
 Now includes FreeBSD:
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

Oh, one more question I've been meaning to ask for a while: Other than ridiculous corner cases (like needing more than 2 GB RAM for CTFE or not having 32-bit libs installed) is there any good reason to prefer either the 64-bit or 32-bit binary on a 64-bit system?

I think that native is generally preferred. I don't know what the impact on performance is for sure either way, but I think that it's generally expected that native applications are going to perform better (though as I understand it, that's not always true). A _big_ reason is simply ease of installation. If you run 32-bit dmd, you need to have the 32-bit versions of certain libraries installed. Depending on your distro and what you've been doing, odds are that they aren't installed (someone who's been using dmd obviously will have them installed, but your average 64-bit Linux user probably won't). So, more is required to get the 32-bit version working than the 64-bit version. So, other than RAM issues or library issues? There _may_ be a performance boost, but then again, there may not. Generally however, distros are going to prefer native binaries as will most users. - Jonathan M Davis
May 13 2011
prev sibling next sibling parent Extrawurst <spam extrawurst.org> writes:
On 13.05.2011 23:27, Walter Bright wrote:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

the changelog mentions: "Bugzilla 1336: Inconsistent __traits usage" this links to http://d.puremagic.com/issues/show_bug.cgi?id=1336 which has absolutely nothing to do with __traits and was fixed in 2007: "Issue 1336 - Internal error when trying to construct a class declared within a unittest from a templated class"
May 13 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Corrected links!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.068.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.053.zip

May 13 2011
next sibling parent Extrawurst <spam extrawurst.org> writes:
On 14.05.2011 03:23, Walter Bright wrote:
 Corrected links!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.068.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.053.zip


Nice! Really great work by all the involved. I love those long lists of fixes ;) Stephan
May 13 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.053.zip


I especially like the stack trace on Windows. Instead of naming the beta versions of 2.053 just "2.053" I suggest to name them something like "2.053beta1", "2.053beta2", "2.053beta3", etc. So it's easy to see when I am running a beta compiler, and in my bug reports I know what one of the beta release it is. Bye, bearophile
May 14 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Do you get the symbol names displayed without running cv2pdb on the exe?

I am seeing the symbol names too (Windows Vista). Bye, bearophile
May 14 2011
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP, 
which does not work. You probably need some version 6.x, 6.11.1.404 from 
the "Microsoft Debugging Tools for Windows" worked for me.

http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi

There is a newer version available, but it seems you have to install the 
full Windows SDK for this.

Andrej Mitrovic wrote:
 Hmm.. so it might be an XP issue. I'll give Win7 a try later.

May 14 2011
parent Rainer Schuetze <r.sagitario gmx.de> writes:
Andrej Mitrovic wrote:
 On 5/15/11, Rainer Schuetze <r.sagitario gmx.de> wrote:
 You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP,
 which does not work. You probably need some version 6.x, 6.11.1.404 from
 the "Microsoft Debugging Tools for Windows" worked for me.

 http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi

 There is a newer version available, but it seems you have to install the
 full Windows SDK for this.

 Andrej Mitrovic wrote:
 Hmm.. so it might be an XP issue. I'll give Win7 a try later.


No, I have had version 6.12.2.633 installed. I also gave your older link a try, it didn't help. I've also tried it on Windows7 after installing debugging tools via the SDK, and that also didn't help. I really don't understand what is causing this issue. Tried compiling via -debug -g, and -debug -gc. The only other thing I can think of is if there is some other dependency which I might be missing. Maybe I'll take a look at the new phobos sources later and try figuring out what is going on.

Is it failing for every executable or only for more complex stuff? I guess any version of dbghelp.dll might stumble over the debug info of larger programs, e.g. if they contain compressed symbols, symbols longer than 255 characters, inconsistent debug info, etc. cv2pdb also fixes various issues, but these might be unrelated to the symbols necessary for the stack dump.
May 15 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/14/11, bearophile <bearophileHUGS lycos.com> wrote:
 Walter:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.053.zip


I especially like the stack trace on Windows.

Do you get the symbol names displayed without running cv2pdb on the exe?
May 14 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 Corrected links!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.068.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.053.zip


Very Nice! Thank you and everyone involved! Thanks to Don for his CTFE-related work. However, you might want to update the uploaded source after a fix for the following: druntime uses octal literals. Also, not having the full druntime source handy apparently means some code wont CTFE. Is there any reason there is an "import" directory in druntime? /druntime/core/sys/posix/sys/wait.d(78): octal literals 0177 are deprecated, use std.conv.octal!177 instead /druntime/core/sys/posix/sys/wait.d(81): octal literals 0177 are deprecated, use std.conv.octal!177 instead /druntime/core/sys/posix/sys/wait.d(100): octal literals 0177 are deprecated, use std.conv.octal!177 instead /druntime/core/sys/posix/sys/wait.d(103): octal literals 0177 are deprecated, use std.conv.octal!177 instead /druntime/core/sys/posix/fcntl.d(103): octal literals 0100 are deprecated, use std.conv.octal!100 instead /druntime/core/sys/posix/fcntl.d(104): octal literals 0200 are deprecated, use std.conv.octal!200 instead /druntime/core/sys/posix/fcntl.d(105): octal literals 0400 are deprecated, use std.conv.octal!400 instead /druntime/core/sys/posix/fcntl.d(106): octal literals 01000 are deprecated, use std.conv.octal!1000 instead /druntime/core/sys/posix/fcntl.d(108): octal literals 02000 are deprecated, use std.conv.octal!2000 instead /druntime/core/sys/posix/fcntl.d(109): octal literals 04000 are deprecated, use std.conv.octal!4000 instead /druntime/core/sys/posix/fcntl.d(110): octal literals 010000 are deprecated, use std.conv.octal!10000 instead /druntime/core/sys/posix/sys/stat.d(142): octal literals 0400 are deprecated, use std.conv.octal!400 instead /druntime/core/sys/posix/sys/stat.d(143): octal literals 0200 are deprecated, use std.conv.octal!200 instead /druntime/core/sys/posix/sys/stat.d(144): octal literals 0100 are deprecated, use std.conv.octal!100 instead /druntime/core/sys/posix/sys/stat.d(157): octal literals 04000 are deprecated, use std.conv.octal!4000 instead /druntime/core/sys/posix/sys/stat.d(158): octal literals 02000 are deprecated, use std.conv.octal!2000 instead /druntime/core/sys/posix/sys/stat.d(159): octal literals 01000 are deprecated, use std.conv.octal!1000 instead /druntime/core/sys/posix/sys/stat.d(219): octal literals 0400 are deprecated, use std.conv.octal!400 instead /druntime/core/sys/posix/sys/stat.d(220): octal literals 0200 are deprecated, use std.conv.octal!200 instead /druntime/core/sys/posix/sys/stat.d(221): octal literals 0100 are deprecated, use std.conv.octal!100 instead /druntime/core/sys/posix/sys/stat.d(234): octal literals 04000 are deprecated, use std.conv.octal!4000 instead
May 14 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2011 2:49 PM, Timon Gehr wrote:
 Also, not having the full druntime source handy apparently means some code wont
 CTFE.

What is missing?
May 14 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
Walter Bright wrote:
 On 5/14/2011 2:49 PM, Timon Gehr wrote:
 Also, not having the full druntime source handy apparently means some code wont
 CTFE.

What is missing?

I stumbled over foreach(dchar c; char_array); It will complain that "_aApplycd2" is not defined. Interestingly, it does not even work when importing the druntime source after all. druntime also has some deprecated volatile statements btw. Timon
May 14 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2011 4:41 PM, Timon Gehr wrote:
 Walter Bright wrote:
 On 5/14/2011 2:49 PM, Timon Gehr wrote:
 Also, not having the full druntime source handy apparently means some code wont
 CTFE.

What is missing?

I stumbled over foreach(dchar c; char_array); It will complain that "_aApplycd2" is not defined. Interestingly, it does not even work when importing the druntime source after all.

It should be in dmd2/src/druntime/src/rt/aApply.d
 druntime also has some deprecated volatile statements btw.


 Timon

May 14 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Hmm.. so it might be an XP issue. I'll give Win7 a try later.
May 14 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/15/11, Rainer Schuetze <r.sagitario gmx.de> wrote:
 You have to update dbghelp.dll. It's version is 5.1.2600.5512 on my XP,
 which does not work. You probably need some version 6.x, 6.11.1.404 from
 the "Microsoft Debugging Tools for Windows" worked for me.

 http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi

 There is a newer version available, but it seems you have to install the
 full Windows SDK for this.

 Andrej Mitrovic wrote:
 Hmm.. so it might be an XP issue. I'll give Win7 a try later.


No, I have had version 6.12.2.633 installed. I also gave your older link a try, it didn't help. I've also tried it on Windows7 after installing debugging tools via the SDK, and that also didn't help. I really don't understand what is causing this issue. Tried compiling via -debug -g, and -debug -gc. The only other thing I can think of is if there is some other dependency which I might be missing. Maybe I'll take a look at the new phobos sources later and try figuring out what is going on.
May 15 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
A simple app like:
void foo()
{
    throw new Exception("");
}
void main() { foo(); }

$ dmd -debug -g testexc.d && testexc.exe:
D:\dev\code\d_code>object.Exception testexc.d(3):
----------------
40CD40
40CBB7
4025EB
4021E7
411FC1
----------------

$ cv2pdb testexc.exe testexc.exe
$ testexc.exe
object.Exception testexc.d(3):
----------------
D:\dev\code\d_code\testexc.d(5): D main

cv2pdb creates a .pdb file with symbol names. If I delete the file the
symbols won't display again.
It didn't work on a fresh Win7 with the debugging sdk installed on a
virtual machine, unless I used cv2pdb on the exe. So I'm not sure
what's wrong.
May 15 2011
prev sibling next sibling parent reply Mafi <mafi example.org> writes:
Am 13.05.2011 23:27, schrieb Walter Bright:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

I just wanted to say that you made my day but then I tried to compile one of my projetcs and assertion failures in the compiler! :0 ! Finally I've tracked it done and the problem is import std.conv; enum s1 = to!string('\uE000'+ 6); //works without s enum s2 = cast(dchar)('\uE000'+ 6); //works without s enum s = to!string(cast(dchar)('\uE000'+ 6)); causes "Assertion failure: '(newval->op == TOKarrayliteral || newval->op == TOKassocarrayliteral || newval->op == TOKstring || newval->op == TOKslice || newval->op == TOKnull)' on line 2680 in file 'interpret.c'"
May 14 2011
parent reply Extrawurst <spam extrawurst.org> writes:
On 14.05.2011 15:23, Mafi wrote:
 Am 13.05.2011 23:27, schrieb Walter Bright:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

I just wanted to say that you made my day but then I tried to compile one of my projetcs and assertion failures in the compiler! :0 ! Finally I've tracked it done and the problem is import std.conv; enum s1 = to!string('\uE000'+ 6); //works without s enum s2 = cast(dchar)('\uE000'+ 6); //works without s enum s = to!string(cast(dchar)('\uE000'+ 6)); causes "Assertion failure: '(newval->op == TOKarrayliteral || newval->op == TOKassocarrayliteral || newval->op == TOKstring || newval->op == TOKslice || newval->op == TOKnull)' on line 2680 in file 'interpret.c'"

posted bugzilla ? http://d.puremagic.com/issues/
May 14 2011
parent reply Mafi <mafi example.org> writes:
Am 14.05.2011 17:09, schrieb Extrawurst:
 On 14.05.2011 15:23, Mafi wrote:
 Am 13.05.2011 23:27, schrieb Walter Bright:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

I just wanted to say that you made my day but then I tried to compile one of my projetcs and assertion failures in the compiler! :0 ! Finally I've tracked it done and the problem is import std.conv; enum s1 = to!string('\uE000'+ 6); //works without s enum s2 = cast(dchar)('\uE000'+ 6); //works without s enum s = to!string(cast(dchar)('\uE000'+ 6)); causes "Assertion failure: '(newval->op == TOKarrayliteral || newval->op == TOKassocarrayliteral || newval->op == TOKstring || newval->op == TOKslice || newval->op == TOKnull)' on line 2680 in file 'interpret.c'"

posted bugzilla ? http://d.puremagic.com/issues/

Could somebody please do this for me. Mafi
May 14 2011
parent Mafi <mafi example.org> writes:
Am 14.05.2011 18:14, schrieb Mafi:
 Am 14.05.2011 17:09, schrieb Extrawurst:
 On 14.05.2011 15:23, Mafi wrote:
 Am 13.05.2011 23:27, schrieb Walter Bright:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

I just wanted to say that you made my day but then I tried to compile one of my projetcs and assertion failures in the compiler! :0 ! Finally I've tracked it done and the problem is import std.conv; enum s1 = to!string('\uE000'+ 6); //works without s enum s2 = cast(dchar)('\uE000'+ 6); //works without s enum s = to!string(cast(dchar)('\uE000'+ 6)); causes "Assertion failure: '(newval->op == TOKarrayliteral || newval->op == TOKassocarrayliteral || newval->op == TOKstring || newval->op == TOKslice || newval->op == TOKnull)' on line 2680 in file 'interpret.c'"

posted bugzilla ? http://d.puremagic.com/issues/

Could somebody please do this for me. Mafi

http://d.puremagic.com/issues/show_bug.cgi?id=6001
May 15 2011
prev sibling next sibling parent reply Joel Christensen <joelcnz gmail.com> writes:
Looks like enum's are tighter (eg. 'enum last = media[ $ - 1 ];' doesn't 
work now). It was working in 52. I had heard it might be relaxed, not 
tightened. I get the error, 'cannot be read at compile time'.

Also immutable imstr = "test"; printf( toStringz( imstr ) ); wasn't 
working at first, but works now for some reason.

Good to have an update though.

bye,
joelcnz
May 15 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-15 03:50, Joel Christensen wrote:
 Looks like enum's are tighter (eg. 'enum last = media[ $ - 1 ];' doesn't
 work now). It was working in 52. I had heard it might be relaxed, not
 tightened. I get the error, 'cannot be read at compile time'.
 
 Also immutable imstr = "test"; printf( toStringz( imstr ) ); wasn't
 working at first, but works now for some reason.
 
 Good to have an update though.

A lot of CTFE stuff was rewritten. What all of the implications of that are, I don't know, but according to Don (who did the rewrite), there are cases which compiled before but didn't generate correct code. I don't know if there were any cases which compiled which were supposed to be illegal. Regardless, because there was a major rewrite for CTFE, the risk of CTFE bugs or behavioral changes is higher than is the case for most releases. - Jonathan M Davis
May 15 2011
next sibling parent reply Joel Christensen <joelcnz gmail.com> writes:
Thanks for the reply Jonathan.

I guess it promotes less buggy programs.

- Joel
May 15 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2011 4:24 AM, Joel Christensen wrote:
 Thanks for the reply Jonathan.

 I guess it promotes less buggy programs.

Please submit bugzilla bug reports for any issues you think should work but do not.
May 15 2011
prev sibling parent Don <nospam nospam.com> writes:
Jonathan M Davis wrote:
 On 2011-05-15 03:50, Joel Christensen wrote:
 Looks like enum's are tighter (eg. 'enum last = media[ $ - 1 ];' doesn't
 work now). It was working in 52. I had heard it might be relaxed, not
 tightened. I get the error, 'cannot be read at compile time'.

 Also immutable imstr = "test"; printf( toStringz( imstr ) ); wasn't
 working at first, but works now for some reason.

 Good to have an update though.

A lot of CTFE stuff was rewritten. What all of the implications of that are, I don't know, but according to Don (who did the rewrite), there are cases which compiled before but didn't generate correct code. I don't know if there were any cases which compiled which were supposed to be illegal.

There are VERY MANY cases which compiled before, which were supposed to be illegal. The compiler used to accept a variable where it needed a compile-time constant!
 Regardless,
 because there was a major rewrite for CTFE, the risk of CTFE bugs or 
 behavioral changes is higher than is the case for most releases.

To clarify: Two massive fixes were made, which are independent of each other: (1) CONSTANT FOLDING: any case where a compile-time value is required now MUST be a compile-time value. If a compile-time value is not required, there is no attempt to interpret it. This fixed many accepts-invalid bugs. (2) CTFE: array literals no longer use copy-on-write (which gave totally wrong semantics). This fixed many wrong-code bugs. Fixing (2) also allowed a huge number of CTFE bugs to be fixed. This particular example is a consequence of (1), and has nothing to do with the CTFE changes.
May 16 2011
prev sibling parent reply Jonathan Crapuchettes <jcrapuchettes gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'm getting a segfault while compiling my code with the 64-bit version of dmd 
2.053. I can't seem to figure out where the problem exists, but something is 
making me think that it is a problem with std.parallelism. Attached is the 
output of dmd with -v.

Walter Bright wrote:
 Thanks for everyone's hard work on this release!

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.067.zip

 Now includes FreeBSD:

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.052.zip

May 16 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2011 10:11 AM, Jonathan Crapuchettes wrote:
 I'm getting a segfault while compiling my code with the 64-bit version of dmd
 2.053. I can't seem to figure out where the problem exists, but something is
 making me think that it is a problem with std.parallelism. Attached is the
 output of dmd with -v.

Please, all bug reports should be posted to bugzilla.
May 16 2011