www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.13.0 alpha 2 released! Please help test!

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

The second alpha release of LDC release 0.13.0 is here! It is 
based on the 2.064.2 front-end and LLVM 3.1-3.4 (OS X: LLVM 
3.2/3.4 only).

Please refer to the GitHub release page for the preliminary 
change log and the
package download links:
https://github.com/ldc-developers/ldc/releases/tag/v0.13.0-alpha2

There was an overwhelming feedback on the first alpha release. I 
was able to integrate most of the suggestions made. But I also 
decided to postpone some of them to release 0.14.0:

- Add line numbers to the error messages produced by -nogc.
- Provide a binary which can compile for ARM targets. (This makes 
only sense if


The rdmd tool is only included in the Debian package. I will 
integrate it soon, too.

Important: This is an alpha version and contains known bugs. Be 
sure to read the section "Known bugs (release blocker)" in the 
preliminary change log.

MD5 checksums for the release packages:

49777584981249e79d053136dadd7883  ldc-0.13.0-alpha2-src.tar.gz
ec732a2631d10bffad3585c15d73785f  
ldc2-0.13.0-alpha2-linux-x86.tar.gz
4144fcc98ad251d62bece61f51122672  
ldc2-0.13.0-alpha2-linux-x86.tar.xz
6a4b6174bf3d96490be2d6159ca1ec1f  
ldc2-0.13.0-alpha2-linux-x86_64.tar.gz
8e5fe8b7f2abd6bea349cad4fff36a52  
ldc2-0.13.0-alpha2-linux-x86_64.tar.xz
9ce18d8735994af9babcbcbf1cefb8f7  ldc2-0.13.0-alpha2-mingw-x86.7z
c81a6a2999ab6b72f0ea5115d0caf1e8  ldc2-0.13.0-alpha2-mingw-x86.zip
52c6fd91e24a77bef3ff2955b306a197  
ldc2-0.13.0-alpha2-osx-x86_64.tar.gz
3c4609a235238611118d63fa7bb946f9  
ldc2-0.13.0-alpha2-osx-x86_64.tar.xz

As always, the Win32/MinGW packages require a recent version of 
the mingw-w64 toolchain, see the (new) README file for details.

There is no Win64/MSVC package because I found a severe bug in 
the Win64/MSVC port. I hope to have this fixed for the beta1 
release.

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
Mar 29 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 ldc2-0.13.0-alpha2-mingw-x86.7z



 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.


This second program still crashes at run-time (Windows 32 bit):
http://rosettacode.org/wiki/Sokoban#Faster_Version

Bye,
bearophile
Mar 29 2014
next sibling parent reply "Joakim" <joakim airpost.net> writes:
On Saturday, 29 March 2014 at 18:59:43 UTC, bearophile wrote:

 Kai Nacke:


 ldc2-0.13.0-alpha2-mingw-x86.7z



 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.


 This second program still crashes at run-time (Windows 32 bit):
 http://rosettacode.org/wiki/Sokoban#Faster_Version

 Bye,
 bearophile


I wonder if it'd be worthwhile to use the D Rosetta code 
implementations as a continuous build test for all 3 compilers, 
as some have suggested D do with as many open source D libraries 
as it can.  You'd think the Rosetta code would do a good job of 
exercising many parts of D.  These could be useful for not just 
regressions but tracking performance over time.
Mar 31 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Joakim:


 I wonder if it'd be worthwhile to use the D Rosetta code 
 implementations as a continuous build test for all 3 compilers,


I am using those programs also as regression/performance testing 
for dmd/ldc2, but I run those tests once in a while (using Python 
scripts that try to compile all the Rosettacode entries kept in a 
directory), and it's not "continuous".

Bye,
bearophile
Mar 31 2014
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
Hi bearophile!

On Saturday, 29 March 2014 at 18:59:43 UTC, bearophile wrote:

 This second program still crashes at run-time (Windows 32 bit):
 http://rosettacode.org/wiki/Sokoban#Faster_Version


I identified the problem. The program declares a static array 
with zero elements. Using the ptr property of this member leads 
to the crash. If you change CellIndex[0] c_; to CellIndex[1] c_; 
then the crash is gone.

With this reduced test case I know need to figure out whats going 

(https://github.com/ldc-developers/ldc/issues/598) to track this 
problem.

Regards,
Kai
Apr 13 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 I identified the problem. The program declares a static array 
 with zero elements.


Yes, recently zero-length arrays were improved in DMD right to 
allow that better kind of usage in variable length structs. Past 
versions (visible in the Revision History in that Rosettacode 
site) used more awkward code, like:

(cast(CellIndex*)&state.c_)[i] = x;

because until recently the .ptr field of a zero length array was 
null. Recently this was fixed and now it's not null any more. It 
returns the start address. So you can use (you still need to use 
.ptr because the length is zero):

c_.ptr[i] = x;

Bye,
bearophile
Apr 14 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On 14 Apr 2014, at 7:57, Kai Nacke wrote:

 With this reduced test case I know need to figure out whats going on 

 (https://github.com/ldc-developers/ldc/issues/598) to track this 
 problem.


I added a link to the upstream bug to the GitHub ticket. Don't have a 
build of the 2.065 branch handy on this machine, though, so I didn't 
close the issue yet.

David
Apr 14 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Nadlinger:


 I added a link to the upstream bug to the GitHub ticket. Don't 
 have a build of the 2.065 branch handy on this machine, though, 
 so I didn't close the issue yet.


So it was not a LDC2 bug, it's just not yet updated to 2.065. 
Sorry for my wrong report.

Bye,
bearophile
Apr 14 2014
parent "David Nadlinger" <code klickverbot.at> writes:
On 14 Apr 2014, at 14:40, bearophile wrote:

 David Nadlinger:


 I added a link to the upstream bug to the GitHub ticket. Don't have a 
 build of the 2.065 branch handy on this machine, though, so I didn't 
 close the issue yet.


 So it was not a LDC2 bug, it's just not yet updated to 2.065. Sorry 
 for my wrong report.


No worries! It's easy to mix up the different versions right now, 
especially since LDC master is not even on 2.064 yet, but the current 
alpha release is based on 2.064.2.

David
Apr 14 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I am also seeing problems with this in the latest two betas (but 
not in the precedent ldc2 version):

http://rosettacode.org/wiki/Left_factorials#D


....>ldmd2 -O -release -inline -noboundscheck left_factorials.d
left_factorials.obj:fake:(.text$__D3std8internal4math11biguintcore7BigUint13__T6mulIntTmZ6mulIntFNaS3std8internal4math11biguintcore7BigUintmZS3std8internal4math
11biguintcore7BigUint+0xfd): undefined reference to 
`_D3std8internal4math10biguintx8625__T15multibyteMulAddVa43Z15multibyteMulAddFNaAkxAkkkZk'
...\ldc2\bin/../lib/libphobos-ldc.a(biguintx86.obj):fake:(.text+0xad9): 
undefined reference to 
`_D3std8internal4math10biguintx8625__T15multi
byteMulAddVa43Z15multibyteMulAddFNaAkxAkkkZk'
collect2.exe: error: ld returned 1 exit status
Error: ...\MinGW\bin\gcc.exe failed with status: 1

Bye,
bearophile
Mar 30 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi bearophile!

On Sunday, 30 March 2014 at 07:53:33 UTC, bearophile wrote:

 I am also seeing problems with this in the latest two betas 
 (but not in the precedent ldc2 version):

 http://rosettacode.org/wiki/Left_factorials#D


I can reproduce this on mingw but not on Linux. Strange.

Regards,
Kai
Mar 31 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 I can reproduce this on mingw but not on Linux. Strange.


OK. There is also the other problem with the second Sokoban :-)

Bye,
bearophile
Mar 31 2014
parent "Kai Nacke" <kai redstar.de> writes:
Hi bearophile!

On Monday, 31 March 2014 at 16:38:11 UTC, bearophile wrote:

 OK. There is also the other problem with the second Sokoban :-)


I am doing something wrong here. The code produce a compile error 
on Linux (around line 235 / 239) but compiles on mingw. And yes, 
it crashes then at runtime.

Regards,
Kai
Mar 31 2014
prev sibling next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Monday, 31 March 2014 at 15:47:20 UTC, Kai Nacke wrote:

 Hi bearophile!

 On Sunday, 30 March 2014 at 07:53:33 UTC, bearophile wrote:

 I am also seeing problems with this in the latest two betas 
 (but not in the precedent ldc2 version):

 http://rosettacode.org/wiki/Left_factorials#D


 I can reproduce this on mingw but not on Linux. Strange.

 Regards,
 Kai


Somewhere in the code, an additional _ is added to the mangled 
name. Therefore the link error...

Regards,
Kai
Mar 31 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On 31 Mar 2014, at 17:47, Kai Nacke wrote:

 On Sunday, 30 March 2014 at 07:53:33 UTC, bearophile wrote:

 I am also seeing problems with this in the latest two betas (but not 
 in the precedent ldc2 version):

 http://rosettacode.org/wiki/Left_factorials#D


 I can reproduce this on mingw but not on Linux. Strange.


Without having looked into the issue at all, my first guess would be 
that this might be a name mangling issue with the Win32 calling 
convention (either prepended underscore or an extra  <n> suffix).

David
Mar 31 2014
parent "Kai Nacke" <kai redstar.de> writes:
On Monday, 31 March 2014 at 17:13:05 UTC, David Nadlinger wrote:

 On 31 Mar 2014, at 17:47, Kai Nacke wrote:

 On Sunday, 30 March 2014 at 07:53:33 UTC, bearophile wrote:

 I am also seeing problems with this in the latest two betas 
 (but not in the precedent ldc2 version):

 http://rosettacode.org/wiki/Left_factorials#D


 I can reproduce this on mingw but not on Linux. Strange.


 Without having looked into the issue at all, my first guess 
 would be that this might be a name mangling issue with the 
 Win32 calling convention (either prepended underscore or an 
 extra  <n> suffix).

 David


weak symbols are not really supported on mingw. I changed the 
assembler output to look like code generated from D templates 
(using .linkonce discard). Now it links & runs.

Regards,
Kai
Apr 12 2014
prev sibling parent reply Martin Krejcirik <mk-junk i-line.cz> writes:
On 29.3.2014 19:32, Kai Nacke wrote:

 4144fcc98ad251d62bece61f51122672  ldc2-0.13.0-alpha2-linux-x86.tar.xz


Could this be compiled with glibc 2.13 ? It doesn't work on Debian wheezy.

-- 
mk
Mar 30 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 30 March 2014 at 16:53:37 UTC, Martin Krejcirik wrote:

 On 29.3.2014 19:32, Kai Nacke wrote:

 4144fcc98ad251d62bece61f51122672  
 ldc2-0.13.0-alpha2-linux-x86.tar.xz


 Could this be compiled with glibc 2.13 ? It doesn't work on 
 Debian wheezy.


It is compiled on Ubuntu 12 TLS. It uses glibc-2.15.

Regards,
Kai
Mar 30 2014
parent "Kagamin" <spam here.lot> writes:
On Sunday, 30 March 2014 at 17:55:56 UTC, Kai Nacke wrote:

 Ubuntu 12 TLS.


Nice pun :)
Mar 30 2014