www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

reply Kai Nacke <kai redstar.de> writes:
Hi everyone!

On behalf of the LDC team I am proud to announce the LDC 0.16.0 
alpha3 release!
It is based on the 2.067.1 front-end and LLVM 3.1-3.7 (OS X: no 
support for 3.3).

This alpha version fixes some issues and adds new features. The 
LDC team already considers this the best LDC release of all times!
Most important changes are:

- Frontend is now at 2.067.1
- LLVM 3.7 is supported
- DMD-style coverage analysis is added
- ABI changes which fixes a lot of bugs in the Win64 compiler

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

Note: This release has alpha quality. There are known and unknown 
bugs left. Please test it with your projects!

Due to a library build problem with Phobos there is currently no 
MinGW32 version. !!!Volunteer help wanted!!!

MD5 checksums for the release packages:

7e89a02a0b31f24cbaad16172761d3c4 ldc-0.16.0-alpha3-src.tar.gz
77a85487d7caa14af3b0845c8468bb8f 
ldc2-0.16.0-alpha3-linux-x86.tar.gz
07717673e247956348ebcf4df19d2b4f 
ldc2-0.16.0-alpha3-linux-x86.tar.xz
2b4f07223166e4c00e8011f373895b02 
ldc2-0.16.0-alpha3-linux-x86_64.tar.gz
9129ff40f496ee850e14f75ddae50e9f 
ldc2-0.16.0-alpha3-linux-x86_64.tar.xz
cba685f75d9e04e052032d3bf74277fb 
ldc2-0.16.0-alpha3-osx-x86_64.tar.gz
039b64aa8734670c718ad7aa88cb4cac 
ldc2-0.16.0-alpha3-osx-x86_64.tar.xz
ede1d89ef79d36fc32e9fcdcde1cbaf2 ldc2-0.16.0-alpha3-win64-msvc.zip

Regarding the binaries:
The Linux binaries are built on Ubuntu 12.04 LTS with gcc 4.8.x 
and LLVM 3.6.2. They work on Ubuntu 12.04 LTS (or later) without 
installing additional software.

The OS X binaries are now built on OS X 10.10. It is currently 
unknown if this causes backwards compatibility issues.

The Win64 MSVC version is still considered alpha quality. It is 
built with VS2013 using LLVM 3.7 in release mode. The 
distribution now contains a precompiled libcurl 7.40.0 from 
http://d.darktech.org/libcurl.html.
Attention: There is a regression in LDC or a bug in LLVM which 
currently requires the use of linker flag -L/FORCE:MULTIPLE 

You find the build script here: 
https://github.com/ldc-developers/ldc-scripts/blob/master/ldc2-win64/RELEASE.proj

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
Sep 16 2015
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
Is this version supposed to contain the fix for this bug?
https://github.com/ldc-developers/ldc/issues/1061

Because I still get this error:
Error: failed to create path to file: 
.dub/obj/../../.dub/packages/memutils-0.3.5/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a
Sep 17 2015
next sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 17 Sep 2015, at 12:20, Marc Schütz via digitalmars-d-ldc wrote:

 Is this version supposed to contain the fix for this bug?
 https://github.com/ldc-developers/ldc/issues/1061


The workaround commit 
https://github.com/ldc-developers/ldc/commit/2a206453c0a60d31ff37
2573127ae22e9efd8f3 
seems to be part of the release tag at least.


 Because I still get this error:
 Error: failed to create path to file: 
 .dub/obj/../../.dub/packages/memutils-0.3.5/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a


Could you post this (and the full ldc2 command line) to the GitHub issue 
tracker, please?

  — David
Sep 17 2015
prev sibling next sibling parent ponce <contact gam3sfrommars.fr> writes:
On Thursday, 17 September 2015 at 10:20:26 UTC, Marc Schütz wrote:

 Is this version supposed to contain the fix for this bug?
 https://github.com/ldc-developers/ldc/issues/1061

 Because I still get this error:
 Error: failed to create path to file: 
 .dub/obj/../../.dub/packages/memutils-0.3.5/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a


Reported: https://github.com/ldc-developers/ldc/issues/1084

You can use dub --combined to work around this
Sep 17 2015
prev sibling parent Kai Nacke <kai redstar.de> writes:
On Thursday, 17 September 2015 at 10:20:26 UTC, Marc Schütz wrote:

 Is this version supposed to contain the fix for this bug?
 https://github.com/ldc-developers/ldc/issues/1061

 Because I still get this error:
 Error: failed to create path to file: 
 .dub/obj/../../.dub/packages/memutils-0.3.5/.dub/build/secure-unittest-linux.posix-x86_64-ldc_0-38ACFEB5A4C0EFEDC50803AF380B9A85/libmemutils.a


This is a problem with my "Road Warrior" setup. I need to update 
the build scripts to check for this error. I am already preparing 
the next alpha release to fix this.

Regards,
Kai
Sep 17 2015
prev sibling next sibling parent reply Yazan D <invalid email.com> writes:
I'm having a problem building my project with this version using dub.

Using `dub build --compiler=path-to-ldc/ldc2`:

Error executing command build:
Source file does not exist.

Using `dub build --compiler=path-to-ldc/ldmd2`:

Error: Output file 'package.o' for module 'aw.g2nc' collides with 
previous module 'aw.dp'. See the -oq option
FAIL ../lib/.dub/build/library-debug-linux.posix-x86_64-
ldc_2067-6CBF3AB0F6005CC5D5CF579F69F56135/ awmms-lib staticLibrary
Error executing command build:
/home/administrator/apps/ldc2-0.16.0-alpha3-linux-x86_64/bin/ldmd2 failed 
with exit code 1.

I can't create a minimal test case right now. But, at least for ldmd2, 
the problem seems that I have two package.d files and their output object 
files are colliding.
Sep 17 2015
next sibling parent Yazan D <invalid email.com> writes:
On Thu, 17 Sep 2015 14:49:15 +0000, Yazan D wrote:


 I can't create a minimal test case right now. But, at least for ldmd2,
 the problem seems that I have two package.d files and their output
 object files are colliding.


I will try to create a minimal test case in the next few days if the 
problem is still unclear by then.
Sep 17 2015
prev sibling parent reply ponce <contact gam3sfrommars.fr> writes:
On Thursday, 17 September 2015 at 14:49:15 UTC, Yazan D wrote:

 I'm having a problem building my project with this version 
 using dub.

 Using `dub build --compiler=path-to-ldc/ldc2`:

 Error executing command build:
 Source file does not exist.

 Using `dub build --compiler=path-to-ldc/ldmd2`:

 Error: Output file 'package.o' for module 'aw.g2nc' collides 
 with
 previous module 'aw.dp'. See the -oq option
 FAIL ../lib/.dub/build/library-debug-linux.posix-x86_64-
 ldc_2067-6CBF3AB0F6005CC5D5CF579F69F56135/ awmms-lib 
 staticLibrary
 Error executing command build:
 /home/administrator/apps/ldc2-0.16.0-alpha3-linux-x86_64/bin/ldmd2 failed
 with exit code 1.

 I can't create a minimal test case right now. But, at least for 
 ldmd2, the problem seems that I have two package.d files and 
 their output object files are colliding.


As a work-around for the first bug you can use --combined

The second bug is probably 
https://github.com/D-Programming-Language/dub/issues/634
Make some noise here.
Sep 17 2015
parent Yazan D <invalid email.com> writes:
On Thu, 17 Sep 2015 14:57:40 +0000, ponce wrote:


 
 As a work-around for the first bug you can use --combined
 
 The second bug is probably
 https://github.com/D-Programming-Language/dub/issues/634 Make some noise
 here.


The workaround works perfectly, thanks.
Sep 17 2015
prev sibling next sibling parent Daniel N <ufo orbiting.us> writes:
On Wednesday, 16 September 2015 at 20:01:10 UTC, Kai Nacke wrote:

 Please test it with your projects!


No regressions in my software. After reading the Changelog, I 
wonder how I ever managed without this compiler, best release 
ever!

Thanks,
Daniel N
Sep 17 2015
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
What can I say, it works nicely for me. I just see issues in
arcane fields of SIMD, but could work around it with inline
assembly that compiles to a lot shorter instructions than the
corresponding sequence of intrinsics:

m_sse = __asm!(const(ubyte16)*)("
    sub        $2, $1
    1:
    add        $2, $1
    vpcmpistri $3, ($1), $4
    cmp        $2, %ecx
    je         1b
    add        %rcx, $1
    ", "=r,0,I,K,x,~{ecx}", m_sse, 16, mode, SIMDFromString!cs);

It is just not very intelligible nor portable. Is there a way
to turn the %rcx into a wild card or %rcx/%ecx depending on
pointer width?

-- 
Marco
Sep 19 2015
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 19 Sep 2015, at 20:09, Marco Leise via digitalmars-d-ldc wrote:

 It is just not very intelligible nor portable. Is there a way
 to turn the %rcx into a wild card or %rcx/%ecx depending on
 pointer width?


Not that I know of. My first advice would be to use the intrinsic 
corresponding to vpcmpistri, but you mentioned the generated asm would 
be longer?

  – David
Sep 20 2015
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 20 Sep 2015 16:54:19 +0200
schrieb David Nadlinger via digitalmars-d-ldc
<digitalmars-d-ldc puremagic.com>:


 On 19 Sep 2015, at 20:09, Marco Leise via digitalmars-d-ldc wrote:

 It is just not very intelligible nor portable. Is there a way
 to turn the %rcx into a wild card or %rcx/%ecx depending on
 pointer width?


=20
 Not that I know of. My first advice would be to use the intrinsic=20
 corresponding to vpcmpistri, but you mentioned the generated asm would=20
 be longer?

   =E2=80=93 David


Hell yeah, the GCC intrinsics don't differentiate between a
SIMD register argument and a memory reference. Basically they
take a SIMD vector, but understand that `*simdptr` can be
encoded as a memory reference. It comes down to compiler flags
and other circumstances how an argument is passed to a SIMD
instruction. Now the problem arises when the compilers blindly
assume that all SIMD memory is aligned although SSE4.2
introduces a few instructions that work on unaligned octet
streams (this `vpcmp(i/e)str(i/m)` and at least a crc32
function IIRC) to make life easier.
When these memory references get preloaded into SIMD registers
with an aligned load you get a SEGFAULT - they require an
unaligned load if anything. Long story short, GCC knew about
this 3 years ago and it was decided that using the intrinsic
without manually putting an unaligned load in front is
incorrect. (Unless you use it on aligned data.) But it kind of
defeats the purpose of using a specialized instruction to
speed up string scanning when you have to add bloat around it.
Maybe I'll post what LLVM or GCC would have generated if used
with only intrinsics.

--=20
Marco
Sep 21 2015
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Here is the comparison. I omitted the part of the function
that would be the same in both versions: prolog, epilog and
loading the current position into %rax.

 1st: hand-optimized ASM

  m_sse = __asm!(const(ubyte16)*)("
    1:
    vpcmpistri $3, ($1), $4
    add        $2, $1
    cmp        $2, %ecx
    je         1b
    sub        $2, $1
    add        %rcx, $1
    ", "=r,0,I,K,x,~{ecx}", m_sse, 16, mode, SIMDFromString!cs);

    c5 f8 28 05 01 74 04 00	vmovaps xmm0,XMMWORD PTR [rip+0x47401]
    c4 e3 79 63 00 08	     L: vpcmpistri xmm0,XMMWORD PTR [rax],0x8
    48 83 c0 10			add    rax,0x10
    83 f9 10			cmp    ecx,0x10
    74 f1			je     L
    48 83 e8 10			sub    rax,0x10
    48 01 c8			add    rax,rcx
    48 89 07			mov    QWORD PTR [rdi],rax
    (33 bytes)

  Destructuring a ~200 MiB JSON file takes 348 ms with that.

 2nd: "naive" approach using intrinsics

  int pos;
  do
  {
    ubyte16 sse = __builtin_ia32_lddqu(m_json);
    pos = __builtin_ia32_pcmpistri128(SIMDFromString!cs, sse, mode);
    m_json += pos;
  }
  while (pos == 16);

    48 89 7d f8			mov    QWORD PTR [rbp-0x8],rdi
    48 89 45 f0			mov    QWORD PTR [rbp-0x10],rax
    48 8b 45 f0		     L: mov    rax,QWORD PTR [rbp-0x10]
    c5 fb f0 00			vlddqu xmm0,[rax]
    c5 f8 28 0d 81 74 04 00	vmovaps xmm1,XMMWORD PTR [rip+0x47481]
    c4 e3 79 63 c8 08		vpcmpistri xmm1,xmm0,0x8
    48 63 d1			movsxd rdx,ecx
    48 01 d0			add    rax,rdx
    48 8b 55 f8			mov    rdx,QWORD PTR [rbp-0x8]
    48 89 02			mov    QWORD PTR [rdx],rax
    81 f9 10 00 00 00		cmp    ecx,0x10
    48 89 45 f0			mov    QWORD PTR [rbp-0x10],rax
    74 d1			je     L
    (55 bytes)

  Time: 502 ms

Compiled with ldc-0.16-alpha3, LLVM 3.5.2
 -O4 -mcpu=native -release -boundscheck=off -singleobj
 -disable-inlining

-- 
Marco
Sep 21 2015
parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 21 Sep 2015, at 11:16, Marco Leise via digitalmars-d-ldc wrote:

 Here is the comparison. I omitted the part of the function
 that would be the same in both versions: prolog, epilog and
 loading the current position into %rax. […]


Wow, thanks, that is indeed rather sobering.

 — David
Sep 23 2015