Hi everyone!

On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release!
It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).

This is a really exciting release!

Support for the PowerPC architecture has grown. Linux/PPC64 Little Endian is quite usable. Linux/PPC32 compiles out of the box and can run simple application. There is still lot to do, though.

Even more exciting this release comes with the first official development snapshot of a Win64 compiler targetting the MS C Runtime. Thanks to Trass3r and kinke for their active development!
Please note that this version is really bleeding edge. Please help to find the bugs!

This release does not include a mingw binary because of some build problems. This is on the todo list for alpha2 or beta1 release.

Be sure to read the preliminary change log at the GitHub release page which also has the package download links:
https://github.com/ldc-developers/ldc/releases/tag/v0.15.0-alpha1

MD5 checksums for the release packages:

e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz
9d54267d1734373452563e57d46d831b ldc2-0.15.0-alpha1-linux-x86.tar.gz
ace3a80431a57b7c88986da48a68d03c ldc2-0.15.0-alpha1-linux-x86.tar.xz
cfce02ac3372f943b78adde982cb6059 ldc2-0.15.0-alpha1-linux-x86_64.tar.gz
af0d70c77ef0fe3cb56255c8635a0c46 ldc2-0.15.0-alpha1-linux-x86_64.tar.xz
7d0d5f01de8b26b03017f4056db061d8 ldc2-0.15.0-alpha1-osx-x86_64.tar.gz
673a79025347e4d240e396ca71d0110d ldc2-0.15.0-alpha1-osx-x86_64.tar.xz
1be7e8ab0fa6b74ffb223aaf8d380a8d ldc2-0.15.0-alpha1-win64-msvc.zip

Please be sure to report any bugs at
https://github.com/ldc-developers/ldc/issues, and feel free to drop by
at the digitalmars.D.ldc forums
(http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or
comments.

Thanks to everybody involved in making this happen!

Regards,
Kai

> Even more exciting this release comes with the first official development snapshot of a Win64 compiler targetting the MS C Runtime.

Known issues:
- broken varargs and thus array concatenation of more than 2 operands
- poor debugging info. Make some noise on cfe-dev to get that fixed as it also affects clang-cl ;)

Kai Nacke:

> e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz
> 9d54267d1734373452563e57d46d831b ldc2-0.15.0-alpha1-linux-x86.tar.gz
> ace3a80431a57b7c88986da48a68d03c ldc2-0.15.0-alpha1-linux-x86.tar.xz
> cfce02ac3372f943b78adde982cb6059 ldc2-0.15.0-alpha1-linux-x86_64.tar.gz
> af0d70c77ef0fe3cb56255c8635a0c46 ldc2-0.15.0-alpha1-linux-x86_64.tar.xz
> 7d0d5f01de8b26b03017f4056db061d8 ldc2-0.15.0-alpha1-osx-x86_64.tar.gz
> 673a79025347e4d240e396ca71d0110d ldc2-0.15.0-alpha1-osx-x86_64.tar.xz
> 1be7e8ab0fa6b74ffb223aaf8d380a8d ldc2-0.15.0-alpha1-win64-msvc.zip

Is the 32 bit Windows version missing still?

Bye,
bearophile

Hi bearophile!

On Wednesday, 22 October 2014 at 19:49:28 UTC, bearophile wrote:
> Is the 32 bit Windows version missing still?

I still have to create the mingw32 version. This will be part of the next alpha/beta release. A version targetting Win32 with MS C Runtime is still missing because there is no exception support for 32bit SEH in LLVM.

Regards,
Kai

On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:
> Hi everyone!
>
> On behalf of the LDC team I am proud to announce the LDC 0.15.0
> alpha1 release!
> It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS
> X: no support for 3.3).
>
> This is a really exciting release!
>
> Support for the PowerPC architecture has grown. Linux/PPC64
> Little Endian is quite usable. Linux/PPC32 compiles out of the
> box and can run simple application. There is still lot to do,
> though.
>
> Even more exciting this release comes with the first official
> development snapshot of a Win64 compiler targetting the MS C
> Runtime. Thanks to Trass3r and kinke for their active
> development!
> Please note that this version is really bleeding edge. Please
> help to find the bugs!
>
> This release does not include a mingw binary because of some
> build problems. This is on the todo list for alpha2 or beta1
> release.
>
> Be sure to read the preliminary change log at the GitHub
> release page which also has the package download links:
> https://github.com/ldc-developers/ldc/releases/tag/v0.15.0-alpha1
>
> MD5 checksums for the release packages:
>
> e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz
> 9d54267d1734373452563e57d46d831b
> ldc2-0.15.0-alpha1-linux-x86.tar.gz
> ace3a80431a57b7c88986da48a68d03c
> ldc2-0.15.0-alpha1-linux-x86.tar.xz
> cfce02ac3372f943b78adde982cb6059
> ldc2-0.15.0-alpha1-linux-x86_64.tar.gz
> af0d70c77ef0fe3cb56255c8635a0c46
> ldc2-0.15.0-alpha1-linux-x86_64.tar.xz
> 7d0d5f01de8b26b03017f4056db061d8
> ldc2-0.15.0-alpha1-osx-x86_64.tar.gz
> 673a79025347e4d240e396ca71d0110d
> ldc2-0.15.0-alpha1-osx-x86_64.tar.xz
> 1be7e8ab0fa6b74ffb223aaf8d380a8d
> ldc2-0.15.0-alpha1-win64-msvc.zip
>
> Please be sure to report any bugs at
> https://github.com/ldc-developers/ldc/issues, and feel free to
> drop by
> at the digitalmars.D.ldc forums
> (http://forum.dlang.org/group/digitalmars.D.ldc) for any
> questions or
> comments.
>
> Thanks to everybody involved in making this happen!
>
> Regards,
> Kai


I tried it with a project I'm working on, compilation works OK, but I'm getting extremely bad performance (50-100x overhead compared to DMD) - profiling has shown that some code that should execute at compile-time seems to run at run-time.

I never used LDC before, I don't know if this is a bug or I'm doing something wrong - I'm using LDC through DUB, so I didn't specify command-line args directly. (tried both debug and release builds, but args were passed by DUB)

Can't publish the project (yet), but here's a part of a function annotated by the profiler (perf):


      bool matchComponents(ComponentTypeIDs...)()
      push   %rbp
      mov    %rsp,%rbp
        {
            // Type IDs of processed component types.
            enum processedIDs = componentIDs!ProcessedComponents;
      sub    $0x70,%rsp
      mov    $0x68dae0,%eax
      mov    %eax,%ecx
      mov    $0x4,%eax
      mov    %eax,%esi
      mov    %rdi,-0x40(%rbp)
      mov    %rcx,%rdi
    → callq  _d_newarrayU
      movw   $0x28,0x6(%rdx)
      movw   $0x25,0x4(%rdx)
      movw   $0x21,0x2(%rdx)
      movw   $0x1,(%rdx)
            enum sortedIDs = std.algorithm.sort([ComponentTypeIDs]);
      mov    $0x68e210,%r8d
      mov    %r8d,%edi
      mov    $0x3,%r8d
      mov    %r8d,%esi
      mov    %rax,-0x48(%rbp)
    → callq  _d_newarrayU
.. etc

Note the _d_newarrayU - it seems the array literal is allocated despite only being used at compile-time? On the other hand, sort() doesn't seem to be called.


Same function with DMD (the 'enum' lines don't even show up):

      /// Determine if the current entity contains specified component types.
      bool matchComponents(ComponentTypeIDs...)()
      push   %rbp
      mov    %rsp,%rbp
      sub    $0x18,%rsp
      push   %rbx
      mov    %rdi,-0x8(%rbp)
      mov    -0x8(%rbp),%rax
      mov    (%rax),%rcx
      lea    0x358(%rax),%rdx
      cmp    (%rdx),%rcx
    ↓ jb     2a
      mov    $0x1f1,%edi
    → callq  _D7tharsis6entity11entityrange7__arrayZ
2a:   mov    (%rax),%rbx
      mov    (%rdx),%rax
      mov    0x8(%rdx),%rdx
      mov    (%rdx,%rbx,2),%cx
      neg    %cx
      sbb    %ecx,%ecx
      neg    %ecx
      mov    %cl,-0x10(%rbp)
                return parts.join(" && ");
            }

            // The actual run-time code is here.
            mixin(q{const result = cast(bool)(%s);}.format(matchCode()));
            return result;
      mov    -0x10(%rbp),%al
        }
      pop    %rbx
      leaveq
    ← retq

On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:
> Hi everyone!
>
> On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release!
> It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).

Hi Kai,

wow looks like an amazing release, I did spot a minor issue, the descriptive text for ldmd2 is outdated when it comes to boundscheck.

DMD32 D Compiler v2.066.1
  -boundscheck=[on|safeonly|off]   bounds checks on, in @safe only, or off
  -noboundscheck no array bounds checking (deprecated, use -boundscheck=off)

LDC - the LLVM D compiler (aa0cc4):
  based on DMD v2.066.1 and LLVM 3.6.0git
  Default target: x86_64-pc-windows-msvc
  -noboundscheck turns off array bounds checking for all functions

On Friday, 24 October 2014 at 11:35:10 UTC, Daniel N wrote:
> On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:
>> Hi everyone!
>>
>> On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release!
>> It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).
>
> Hi Kai,
>
> wow looks like an amazing release, I did spot a minor issue, the descriptive text for ldmd2 is outdated when it comes to boundscheck.
>
> DMD32 D Compiler v2.066.1
>   -boundscheck=[on|safeonly|off]   bounds checks on, in @safe only, or off
>   -noboundscheck no array bounds checking (deprecated, use -boundscheck=off)
>
> LDC - the LLVM D compiler (aa0cc4):
>   based on DMD v2.066.1 and LLVM 3.6.0git
>   Default target: x86_64-pc-windows-msvc
>   -noboundscheck turns off array bounds checking for all functions

Hi Daniel!

Thanks for the report. This is really unimplemented functionality.

Regards,
Kai

Hi Kiith-Sa!

On Friday, 24 October 2014 at 00:50:51 UTC, Kiith-Sa wrote:
> On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:
>> Hi everyone!
>>
>> On behalf of the LDC team I am proud to announce the LDC 0.15.0
>> alpha1 release!
>> It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS
>> X: no support for 3.3).
>
>
> I tried it with a project I'm working on, compilation works OK, but I'm getting extremely bad performance (50-100x overhead compared to DMD) - profiling has shown that some code that should execute at compile-time seems to run at run-time.
>
> I never used LDC before, I don't know if this is a bug or I'm doing something wrong - I'm using LDC through DUB, so I didn't specify command-line args directly. (tried both debug and release builds, but args were passed by DUB)

Thanks for trying LDC!

CTFE is done in the frontend therefore there should be no difference between LDC and DMD. But a bug can always creep in...

> Can't publish the project (yet), but here's a part of a function annotated by the profiler (perf):

We really prefer reduced test cases. :-) If you can produce one that would be really great.

>
>       bool matchComponents(ComponentTypeIDs...)()
>       push   %rbp
>       mov    %rsp,%rbp
>         {
>             // Type IDs of processed component types.
>             enum processedIDs = componentIDs!ProcessedComponents;
>       sub    $0x70,%rsp
>       mov    $0x68dae0,%eax
>       mov    %eax,%ecx
>       mov    $0x4,%eax
>       mov    %eax,%esi
>       mov    %rdi,-0x40(%rbp)
>       mov    %rcx,%rdi
>     → callq  _d_newarrayU
>       movw   $0x28,0x6(%rdx)
>       movw   $0x25,0x4(%rdx)
>       movw   $0x21,0x2(%rdx)
>       movw   $0x1,(%rdx)
>             enum sortedIDs = std.algorithm.sort([ComponentTypeIDs]);
>       mov    $0x68e210,%r8d
>       mov    %r8d,%edi
>       mov    $0x3,%r8d
>       mov    %r8d,%esi
>       mov    %rax,-0x48(%rbp)
>     → callq  _d_newarrayU
> .. etc
>
> Note the _d_newarrayU - it seems the array literal is allocated despite only being used at compile-time? On the other hand, sort() doesn't seem to be called.
>
>
> Same function with DMD (the 'enum' lines don't even show up):
>
>       /// Determine if the current entity contains specified component types.
>       bool matchComponents(ComponentTypeIDs...)()
>       push   %rbp
>       mov    %rsp,%rbp
>       sub    $0x18,%rsp
>       push   %rbx
>       mov    %rdi,-0x8(%rbp)
>       mov    -0x8(%rbp),%rax
>       mov    (%rax),%rcx
>       lea    0x358(%rax),%rdx
>       cmp    (%rdx),%rcx
>     ↓ jb     2a
>       mov    $0x1f1,%edi
>     → callq  _D7tharsis6entity11entityrange7__arrayZ
> 2a:   mov    (%rax),%rbx
>       mov    (%rdx),%rax
>       mov    0x8(%rdx),%rdx
>       mov    (%rdx,%rbx,2),%cx
>       neg    %cx
>       sbb    %ecx,%ecx
>       neg    %ecx
>       mov    %cl,-0x10(%rbp)
>                 return parts.join(" && ");
>             }
>
>             // The actual run-time code is here.
>             mixin(q{const result = cast(bool)(%s);}.format(matchCode()));
>             return result;
>       mov    -0x10(%rbp),%al
>         }
>       pop    %rbx
>       leaveq
>     ← retq

I do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch. Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz@forum.dlang.org). Using -singleobj with multiple objects might help, too.

Regards,
Kai

Not sure wether this is an issue at all: I get some strange behaviour when I try to mix dmd and LDC generated *.o-files:
//versions:
DMD64 D Compiler v2.066.0

linux-x86_64 LDC

//code:
module a;

int foo(int a) {
	return a;
}

module b;

import a;
import std.stdio;

void main() {
	writeln(foo(2));
}


dmd a.d -c
ldc2 b.d a.o
./b
output:
object.Exception@/build/src/ldc/runtime/phobos/std/stdio.d(2156): Enforcement failed

dmd a.d -c
ldc2 b.d -c
ldc2 b.o a.o
./b
output:
2

dmd b.d -c
ldc2 b.o a.d
output:
b.o: In Funktion `_D3std9exception105__T12errnoEnforceTiVAyaa35_2f7573722f696e636c7564652f646d642f70686f626f732f7374642f737464696f2e64Vmi2113Z12errnoEnforceFNfiLAyaZi':
b.d:(.text._D3std9exception105__T12errnoEnforceTiVAyaa35_2f7573722f696e636c7564652f646d642f70686f626f732f7374642f737464696f2e64Vmi2113Z12errnoEnforceFNfiLAyaZi+0x6a): Nicht definierter Verweis auf `_d_throwc'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1


If dmd does the linking, there are even more different results...
I also have a ldc version build from github source at 20.10.2014 (0.14 was broken for me) where I get
dmd -c a.d
ldc2 b.d a.o
./b
2
Ungültiger Maschinenbefehl

Note that I usually compile everything with the same compiler and LDC 0.15 seems to work fine. The only minor problem is that I can't use the compilation speed of dmd during development because it is unable to link against my gtkd (compiled by an old LDC version) - not sure wether that is related.

On Friday, 24 October 2014 at 20:56:28 UTC, Anonymus wrote:
> Not sure wether this is an issue at all: I get some strange behaviour when I try to mix dmd and LDC generated *.o-files.

DMD and LDC are indeed not ABI compatible right now,

> (compiled by an old LDC version)

and neither different versions of any one D compiler.

David