digitalmars.D.ldc - LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!
- Kai Nacke (57/57) Sep 16 2015 Hi everyone!
- Marc =?UTF-8?B?U2Now7x0eg==?= (5/5) Sep 17 2015 Is this version supposed to contain the fix for this bug?
- David Nadlinger via digitalmars-d-ldc (7/12) Sep 17 2015 The workaround commit
- ponce (3/8) Sep 17 2015 Reported: https://github.com/ldc-developers/ldc/issues/1084
- Kai Nacke (6/11) Sep 17 2015 This is a problem with my "Road Warrior" setup. I need to update
- Yazan D (15/15) Sep 17 2015 I'm having a problem building my project with this version using dub.
- Yazan D (3/6) Sep 17 2015 I will try to create a minimal test case in the next few days if the
- ponce (5/23) Sep 17 2015 As a work-around for the first bug you can use --combined
- Yazan D (2/8) Sep 17 2015 The workaround works perfectly, thanks.
- Daniel N (6/7) Sep 17 2015 No regressions in my software. After reading the Changelog, I
- Marco Leise (18/18) Sep 19 2015 What can I say, it works nicely for me. I just see issues in
- David Nadlinger via digitalmars-d-ldc (5/8) Sep 20 2015 Not that I know of. My first advice would be to use the intrinsic
- Marco Leise (25/34) Sep 21 2015 Am Sun, 20 Sep 2015 16:54:19 +0200
- Marco Leise (52/52) Sep 21 2015 Here is the comparison. I omitted the part of the function
- David Nadlinger via digitalmars-d-ldc (3/6) Sep 23 2015 Wow, thanks, that is indeed rather sobering.
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
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
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/1061The 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.aCould you post this (and the full ldc2 command line) to the GitHub issue tracker, please? — David
Sep 17 2015
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.aReported: https://github.com/ldc-developers/ldc/issues/1084 You can use dub --combined to work around this
Sep 17 2015
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.aThis 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
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
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
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
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
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
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
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
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: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 MarcoIt 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
Sep 21 2015
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
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