www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.11.0 has been released!

reply David Nadlinger <code klickverbot.at> writes:
Hi all,

As the third round of beta testing did not turn up any new problems,
I'm glad to announce the official release of LDC 0.11.0. A quick
overview of the changes since the last release:

 - Based on the DMD 2.062 frontend.
 - D1 is no longer supported.

 - As with recent versions of DMD, .di file generation now strips
functions bodies. The '-Hkeep-all-bodies' command line has been added
to disable this, like '-inline' does for DMD.
 - LDMD now correctly parses extra arguments for -run and no longer
drops -deps.

 - Previously, due to an oversight LDC always optimized for the
 features of the host CPU, and not for a generic x86/x86_64 CPU as
 expected. This has been fixed; for the old behavior use -march=3Dnative.
 - -O now is equivalent to -O3 (instead of -O2) to match DMD.
 - The GC to stack promotion optimizer pass is enabled by default on
-O2 and higher. It is still *very* conservative, though (due to a
change in the signature of the relevant druntime functions).

 - The LDC_global_crt_ctor/LDC_global_crt_dtor pragmas allow
registering functions to be run during C runtime startup/shutdown. This
is mostly helpful for implementing druntime itself.
 - The LDC_never_inline pragma can now be used to mark functions that
should never be inlined.

 - Passing large static arrays by value no longer leads to horribly
inefficient code and long compile times.
 - A large number of code generation bugs has been fixed, see the
GitHub issue tracker. [1]


Platform support
----------------

 - Linux x86/x86_64: Stable.

 - OS X 10.7+: (Almost) stable. The last few LLVM versions, including
the current 3.2 release, sometimes emit broken exception handling
tables for large stack frames, which can to crashes in libunwind [2]
on throwing exceptions in rare cases. This issue will be fixed in LLVM
3.3, which the next LDC release will be based on. For building 32 bit
applications, the DMD frontend unfortunately gets the alignment of
real-type fields wrong [3], causing issues with initialization of such
structs.

 - Win32/MinGW: An alpha-quality version is available as part of this
release. For use together with [4], see [5] for a more in-depth look
at the current state.

 - Win64/MSVC: Not officially part of this release yet, a preview
version is available here:
http://forum.dlang.org/post/vscpokspiejlckivqsuq forum.dlang.org

For the current state on other platforms such as Linux/PPC64 and ARM,
please refer to the LDC wiki. [6]


Package download
----------------

The below are self-contained ("DMD-style") binary packages that do not
require any installation.

Apart from the changed file names and the addition of a minimal README
file, the release is bit-for-bit identical to the third beta, so there
is no need to re-download the archives if you already have a beta3
package.

If you prefer to build LDC yourself, just grab the source archive and
see the wiki [6] for instructions.

http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-linux-x86.tar.gz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-linux-x86.tar.xz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-linux-x86_64.tar.gz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-linux-x86_64.tar.xz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-mingw-x86.7z
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-osx-x86_64.tar.gz
http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-osx-x86_64.tar.xz
http://d32gngvpvl2pi1.cloudfront.net/ldc-0.11.0-src.tar.gz

MD5 checksums:

1839973c921a6b72580e1e9d6b1ec2e3  ldc2-0.11.0-linux-x86_64.tar.gz
e40e93ff36bba688a4028b12139ba22e  ldc2-0.11.0-linux-x86_64.tar.xz
09cb1a88318a5cf8d63db33c63a33037  ldc2-0.11.0-linux-x86.tar.gz
0dbe83267165eaa7fdc3ecc5ef3a62e1  ldc2-0.11.0-linux-x86.tar.xz
11317c4b9cdbca43e94b9aabc171f9e3  ldc2-0.11.0-mingw-x86.7z
004c79868bb91eb9c85f2a4c5004bebe  ldc2-0.11.0-osx-x86_64.tar.gz
40067905fb7c8022ef8db9d7780ee9a3  ldc2-0.11.0-osx-x86_64.tar.xz
437c2c30970fc98eee49eb0f5b66fd26  ldc-0.11.0-src.tar.gz


Thanks to everybody involved in making this happen!

As usual, the main contact address for anything LDC is the
digitalmars.D.ldc forum (http://forum.dlang.org), which is also
reachable via NNTP and a mailing list interface.

 =E2=80=94 David



[1] https://github.com/ldc-developers/ldc/issues?milestone=3D2&state=3Dclos=
ed
[2] https://github.com/ldc-developers/ldc/issues/362
[3] https://github.com/ldc-developers/ldc/issues/363
[4]
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20W=
in32/Personal%20Builds/rubenvb/gcc-4.8-dw2-release/i686-w64-mingw32-gcc-dw2=
-4.8.0-win32_rubenvb.7z/download
[5] http://klickverbot.at/blog/2013/05/the-state-of-ldc-on-windows/
[6] http://wiki.dlang.org/LDC
Jun 09 2013
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Sunday, 9 June 2013 at 14:35:30 UTC, David Nadlinger wrote:

 11317c4b9cdbca43e94b9aabc171f9e3  ldc2-0.11.0-mingw-x86.7z


Very nice.

Btw, it would be good to note that it requires the MinGW release 
with DW2 (Dwarf afaik) rather than SJLJ exceptions. Otherwise it 
will error at runtime looking for the missing 
"libgcc_s_dw2-1.dll".
Jun 09 2013
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 9 June 2013 at 14:54:39 UTC, Andrej Mitrovic wrote:

 Btw, it would be good to note that it requires the MinGW 
 release with DW2 (Dwarf afaik) rather than SJLJ exceptions. 
 Otherwise it will error at runtime looking for the missing 
 "libgcc_s_dw2-1.dll".


Oh, somehow that paragraph didn't make it in there: It doesn't 
only require a DW2-based release, but also a very recent snapshot 
of mingw-w64, because for TLS support requires a recent assembler 
and fixes to the MinGW C runtime.

Just using the package I linked should work fine.

David
Jun 09 2013
prev sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Sunday, 9 June 2013 at 14:54:39 UTC, Andrej Mitrovic wrote:

 On Sunday, 9 June 2013 at 14:35:30 UTC, David Nadlinger wrote:

 11317c4b9cdbca43e94b9aabc171f9e3  ldc2-0.11.0-mingw-x86.7z


 Very nice.

 Btw, it would be good to note that it requires the MinGW 
 release with DW2 (Dwarf afaik) rather than SJLJ exceptions. 
 Otherwise it will error at runtime looking for the missing 
 "libgcc_s_dw2-1.dll".


Well it's noted in the blog post, I skimmed that part. :)
Jun 09 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
I think SJLJ exception more native for windows.
Also waiting for ldc based on 2.0.63 frontend.
Jun 09 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 9 June 2013 at 17:33:05 UTC, Temtaime wrote:

 I think SJLJ exception more native for windows.


Nah, SEH is the Windows-native exception handling model. SJLJ and 
DW2 EH are both foreign on Win32, and for the use in a typical D 
program, I think SJLJ has too many downsides to be considered 
more than a crude workaround. But, of course, you are more than 
welcome to contribute an LDC patch implementing it. ;)


 Also waiting for ldc based on 2.0.63 frontend.


Work in progress, but there are some internals to be cleaned up 
first.

David
Jun 09 2013
prev sibling next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Sunday, 9 June 2013 at 14:35:30 UTC, David Nadlinger wrote:

 I'm glad to announce the official release of LDC 0.11.0.


The Gentoo ebuild for 0.11.0 is now available. As another 
highlight it contains all patches required for Linux/PPC64.

Kai
Jun 09 2013
prev sibling next sibling parent reply "Richard Webb" <webby beardmouse.org.uk> writes:
 http://d32gngvpvl2pi1.cloudfront.net/ldc2-0.11.0-mingw-x86.7z



fwiw, I just tried to build a simple test app using xmlp with the 
mingw build, and it appears to build and run fine, and is a bit 
faster than the DMD version (parsing an ~18 megabyte test xml 
file into a DOM takes ~2 seconds with the DMD build and ~1.6 
seconds with the LDC build).


Keep up the good work :-)
Jun 11 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 11 June 2013 at 16:52:38 UTC, Richard Webb wrote:

 fwiw, I just tried to build a simple test app using xmlp with 
 the mingw build, and it appears to build and run fine, and is a 
 bit faster than the DMD version […]


Thanks a lot for your post – we simply don't have enough data 
points right now to be able to realistically judge the quality of 
LDC/MinGW, so every bit of feedback helps.

Were you using the personal build from Ruben I linked, or another 
MinGW(-w64) installation?

David
Jun 11 2013
parent reply "Richard Webb" <webby beardmouse.org.uk> writes:
 Were you using the personal build from Ruben I linked, or 
 another MinGW(-w64) installation?


It was the one you linked to.
Jun 11 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
I can help with building LDC on lastest ICC with 
auto-vectorization.
I think it'll improve the perfomance.
Jun 16 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 16 Jun 2013, at 9:07, Temtaime wrote:

 I can help with building LDC on lastest ICC with auto-vectorization.
 I think it'll improve the perfomance.


Did you actually try this out in practice? I wouldn't expect LDC to be 
the kind of code where ICC yields a noticeable speedup.

David
Jun 17 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
Yes, i maked some tests and ICC gives better perfomance without 
code changes in many cases.
Other problem is, if ldc doesn't compiles by ICC.
Jun 20 2013
next sibling parent reply "Michael" <pr m1xa.com> writes:
ICC - Intel C Compiler?

For AMD processors - 
http://developer.amd.com/tools-and-sdks/cpu-development/amd-open64-software-development-kit/

Both Linux only.
Jun 22 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
Yes.
No, ICC available on Windows/MacOS too.

Open64 seems to be out of date.
Jun 24 2013
parent "Michael" <pr m1xa.com> writes:
On Monday, 24 June 2013 at 20:42:26 UTC, Temtaime wrote:

 Yes.
 No, ICC available on Windows/MacOS too.

 Open64 seems to be out of date.


ICC available on commercial basis, not open source. It will great 
if packager will have licence of ICC windows version.

Anyway amd version of open64 seems to be updated and optimized to 
amd chips like ICC for intel chips.
Jun 25 2013
prev sibling parent "Kai Nacke" <kai redstar.de> writes:
On Thursday, 20 June 2013 at 19:40:41 UTC, Temtaime wrote:

 Yes, i maked some tests and ICC gives better perfomance without 
 code changes in many cases.
 Other problem is, if ldc doesn't compiles by ICC.


Do you have some numbers? E.g. compile time for druntime is 
reduced by 15%.

For LDC I suspect that there is no real benefit. As far as I know 
ICC is really great in auto vectorization and similar stuff. LLVM 
and LDC do not seem to be a good target for this...

(One of the performance killer is the memory consumption...)

Kai
Jun 29 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Maybe I have found some more problems. The program:


import core.stdc.stdio, std.math;

void test(in double nLoops) nothrow {
     double rsin = 0.0;
     double rtan = 0.0;

     double i = 0.0;
     while (i < nLoops) {
         rsin = sin(i);
         rtan = tan(i);
         i++;
     }

     printf("i: %f\n", i);
     printf("sin: %f\n", rsin);
     printf("tan: %f\n", rtan);
}

void main() {
     test(2_000_000);
}



DMD seems to print the correct values:

i: 2000000.000000
sin: -0.989602
tan: 6.880292


The program compiled with ldmd2 (on a 32 bit Windows system, with 
no switches) crashes when it tries to print "i". If I comment out 
the printf line of "i" then the program prints:

sin: -0.000000
tan: nan

Bye,
bearophile
Jul 28 2013
parent reply David Nadlinger <code klickverbot.at> writes:
On Sun, Jul 28, 2013 at 7:39 PM, bearophile <bearophileHUGS lycos.com> wrote:

 Maybe I have found some more problems. The program:


Filed as: https://github.com/ldc-developers/ldc/issues/432

David
Jul 28 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I think I have found another small bug:


int foo(in bool b) {
     if (b == true)
         return 1;
     assert(0);
}
void main() {}


If I compile it with:
ldmd2 -O -release -noboundscheck -noruntime test.d

It gives:
Error: No implicit runtime calls allowed with -noruntime option 
enabled

But if I compile that program with those switches, it should turn 
the assert(0) into a HALT instruction, that I think has nothing 
to do with runtime calls.

This is the asm of foo(), it contains a call to __d_assert that I 
think should not be present:

__D4test3fooFxbZi:
	subl	$12, %esp
	testb	$1, %al
	je	LBB0_2
	movl	$1, %eax
	addl	$12, %esp
	ret
LBB0_2:
	movl	$6, 8(%esp)
	movl	$_.str, 4(%esp)
	movl	$6, (%esp)
	calll	__d_assert


This is how dmd compiles the same function with the same 
compilation switches, the assert(0) has become a hlt:

_D4test3fooFxbZi:
         push    EAX
         cmp [ESP],1
         jne LE
         pop ECX
         mov EAX,1
         ret
LE:     hlt

Bye,
bearophile
Jul 31 2013
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On 31 Jul 2013, at 22:53, bearophile wrote:

 I think I have found another small bug:


Again, please consider creating a GitHub account and reporting this and 
any other issues on our bug tracker. It literally takes just one minute, 
and your excellent reports are only in danger of being overlooked here.

Thanks,
David
Jul 31 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Recently I have added to bug reports to LLVM (from D code 
compiled with ldc2), I am not fully sure they are caused by the 
back-end:

http://llvm.org/bugs/show_bug.cgi?id=16723
http://llvm.org/bugs/show_bug.cgi?id=16726

So far I have received no answers, I don't know why. LLVM people 
used to answer me quickly :-)

Bye,
bearophile
Aug 05 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
If I compile this little program:

void main() {
     align(4) double[1600] a;
     align(8) double[1600] b;
     align(16) double[1600] c;
}


With:

ldmd2 -output-ll test.d


I see no warnings nor errors, and the main is:


define i32  _Dmain({ i32, { i32, i8* }* } %unnamed) {
entry:
   %a = alloca [1600 x double], align 8
   %arrayinit.itr = alloca i32, align 4
   %b = alloca [1600 x double], align 8
   %arrayinit.itr8 = alloca i32, align 4
   %c = alloca [1600 x double], align 8
   %arrayinit.itr19 = alloca i32, align 4
   %tmp = getelementptr [1600 x double]* %a, i32 0, i32 0
   store i32 0, i32* %arrayinit.itr
   br label %arrayinit.cond


So it silently ignores the align(). Is this a bug?

Bye,
bearophile
Aug 06 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
import core.simd;
float bar1(float4 data) pure nothrow {
     return data.array[0];
}
struct Foo {
     float4 data;
     alias data this;
}
float bar2(Foo data) pure nothrow {
     return data.array[0];
}
void main() {
     float4 f = [1.5, 2.5, 3.5, 4.5];
     bar1(f);
     bar2(Foo(f));
}


Produces this asm for the bar1 and bar2 functions:

__D4test4bar1FNaNbNhG4fZf:
     pushl   %eax
     vmovss  %xmm0, (%esp)
     flds    (%esp)
     popl    %eax
     ret

__D4test4bar2FNaNbS4test3FooZf:
     pushl   %ebp
     movl    %esp, %ebp
     andl    $-16, %esp
     subl    $16, %esp
     flds    8(%ebp)
     movl    %ebp, %esp
     popl    %ebp
     ret $16

Is that good enough?

Bye,
bearophile
Aug 06 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 5 August 2013 at 21:06:51 UTC, bearophile wrote:

 http://llvm.org/bugs/show_bug.cgi?id=16723
 http://llvm.org/bugs/show_bug.cgi?id=16726

 So far I have received no answers, I don't know why. LLVM 
 people used to answer me quickly :-)


Well, you can send them patches :)
Aug 07 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On 5 Aug 2013, at 23:06, bearophile wrote:

 http://llvm.org/bugs/show_bug.cgi?id=16723
 http://llvm.org/bugs/show_bug.cgi?id=16726

 So far I have received no answers, I don't know why. LLVM people used 
 to answer me quickly :-)


When reporting codegen problems (other than for Clang) to the LLVM bug 
tracker, you should post LLVM IR instead of/in addition to the source 
language code. Otherwise, it is very cumbersome for the LLVM optimizer 
devs to even just have a first look at the issue, at least if they don't 
happen to have an LDC installation lying around.

David
Aug 07 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:


 When reporting codegen problems (other than for Clang) to the 
 LLVM bug tracker, you should post LLVM IR instead of/in 
 addition to the source language code. Otherwise, it is very 
 cumbersome for the LLVM optimizer devs to even just have a 
 first look at the issue, at least if they don't happen to have 
 an LDC installation lying around.


OK, I will add the IR.

Bye,
bearophile
Aug 10 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 31 July 2013 at 20:53:14 UTC, bearophile wrote:

 But if I compile that program with those switches, it should 
 turn the assert(0) into a HALT instruction, that I think has 
 nothing to do with runtime calls.


Yep: https://github.com/ldc-developers/ldc/pull/475

The MinGW floating point related issues you reported are fixed in 
Git master as well.

David
Sep 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:


 The MinGW floating point related issues you reported are fixed 
 in Git master as well.


Good, this encourages me to look for more problems.

If I compile this:


import std.bigint: BigInt;
void main() {
     BigInt(1) + 1;
}


With:
ldmd2 -O -release test.d

Using the LDC 0.11.0 I receive many errors like:

test.obj:fake:(.text$_D3std8internal4math11biguintcore7BigUint19__T11addOrSubIntTmZ11addOrSubIntFxS3std8internal4math11biguintcor...


I compile DMD more than once every week, but I don't look forward 
to compiling LDC2 by myself on Windows. So I'd like LDC2 to 
release pre-compiled binaries for Windows once in a while, like 
once every month.

Bye,
bearophile
Sep 15 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
I don't remember if the round() function was already fixed:


import std.stdio: writeln;
import std.math: round;
void main() {
     writeln(round(1.5));
}



I have also found a little performance bug, take a look at the 
timings below the second version of this Rosettacode task:

http://rosettacode.org/wiki/Zebra_puzzle#Alternative_Version

Bye,
bearophile
Oct 02 2013