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 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
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 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
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 reply 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
parent reply 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
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 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 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


Thanks
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:
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