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

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.

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

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

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 on here. I opened issue #598 (https://github.com/ldc-developers/ldc/issues/598) to track this problem.

Regards,
Kai

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

On 14 Apr 2014, at 7:57, Kai Nacke wrote:
> With this reduced test case I know need to figure out whats going on here. I opened issue #598 (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

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

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