Hi all,

The title pretty much says it all: Since there were no test regressions of merge-2.070 over master anymore, I finished the merge yesterday. LDC built from the master branch is now at version 2.070.2.

Furthermore, I created a merge-2.071 branch that corresponds to DMD v2.071.0-b2. It builds the standard library and passes all unit tests except for release-mode std.math, but there are a bunch of dmd-testsuite failures left. Most of them are due to lack of forwarding -transition=... to the appropriate frontend switches – this would be a good time to finally implement that due to the 313/314 fixes –, but there are a couple of codegen bugs left, too. In particular, we need to figure out what to do with C++ EH interop, and the C++ ABI interface seems to have suffered from some regressions in the wake of the class layout change (see commit history).

I won't be able to spend much time on completing the merge in the upcoming weeks, but it should be fairly easy to go in and fix the remaining issues. They all seem fairly self-contained. It would be really nice to be able to provide a 2.071-based LDC alpha in sync with the upcoming upstream release.

Best,
David

On Sunday, 3 April 2016 at 16:59:38 UTC, David Nadlinger wrote:
> Hi all,
>
> The title pretty much says it all: Since there were no test regressions of merge-2.070 over master anymore, I finished the merge yesterday. LDC built from the master branch is now at version 2.070.2.
>
> Furthermore, I created a merge-2.071 branch that corresponds to DMD v2.071.0-b2. It builds the standard library and passes all unit tests except for release-mode std.math, but there are a bunch of dmd-testsuite failures left. Most of them are due to lack of forwarding -transition=... to the appropriate frontend switches – this would be a good time to finally implement that due to the 313/314 fixes –, but there are a couple of codegen bugs left, too. In particular, we need to figure out what to do with C++ EH interop, and the C++ ABI interface seems to have suffered from some regressions in the wake of the class layout change (see commit history).
>
> I won't be able to spend much time on completing the merge in the upcoming weeks, but it should be fairly easy to go in and fix the remaining issues. They all seem fairly self-contained. It would be really nice to be able to provide a 2.071-based LDC alpha in sync with the upcoming upstream release.
>
> Best,
> David

Grats !
It's amazing

On Sunday, 3 April 2016 at 16:59:38 UTC, David Nadlinger wrote:
> Hi all,
>
> The title pretty much says it all: Since there were no test regressions of merge-2.070 over master anymore, I finished the merge yesterday. LDC built from the master branch is now at version 2.070.2.

Thanks for the merge!

> Furthermore, I created a merge-2.071 branch that corresponds to DMD v2.071.0-b2. It builds the standard library and passes all unit tests except for release-mode std.math, but there are a bunch of dmd-testsuite failures left. Most of them are due to lack of forwarding -transition=... to the appropriate frontend switches – this would be a good time to finally implement that due to the 313/314 fixes –, but there are a couple of codegen bugs left, too. In particular, we need to figure out what to do with C++ EH interop, and the C++ ABI interface seems to have suffered from some regressions in the wake of the class layout change (see commit history).
>
> I won't be able to spend much time on completing the merge in the upcoming weeks, but it should be fairly easy to go in and fix the remaining issues. They all seem fairly self-contained. It would be really nice to be able to provide a 2.071-based LDC alpha in sync with the upcoming upstream release.

Really great. :-)

Regards,
Kai

On 03.04.2016 18:59, David Nadlinger via digitalmars-d-ldc wrote:
> I won't be able to spend much time on completing the merge in the
> upcoming weeks, but it should be fairly easy to go in and fix the
> remaining issues. They all seem fairly self-contained. It would be
> really nice to be able to provide a 2.071-based LDC alpha in sync with
> the upcoming upstream release.

I've pushed a number of changes to the merge-2.071 branch, with the result

- appveyor Windows x64 passes
- appveyor Windows x86 fails for the same test as master, but I cannot reproduce it locally
- travis OSX passes
- travis/circleCI linux fail for 1 unittest, and crash for 2 more

I tried to reproduce the latter in a VM with Ubuntu 16, but also got failures for the master branch. Are there known issues with special configurations? I'm building with LLVM 3.7.1 and LDC 0.17.1 based on DMD 2.068.2 and LLVM 3.8.0.

What's left is catching C++ exceptions, which is only expected to exist for linux/64. I have no idea what to do about this, but could probably implement it for Windows instead ;-)

On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:
>
>
> On 03.04.2016 18:59, David Nadlinger via digitalmars-d-ldc wrote:
>> [...]
>
> I've pushed a number of changes to the merge-2.071 branch, with the result
>
> - appveyor Windows x64 passes
> - appveyor Windows x86 fails for the same test as master, but I cannot reproduce it locally
> - travis OSX passes
> - travis/circleCI linux fail for 1 unittest, and crash for 2 more
>
> I tried to reproduce the latter in a VM with Ubuntu 16, but also got failures for the master branch. Are there known issues with special configurations? I'm building with LLVM 3.7.1 and LDC 0.17.1 based on DMD 2.068.2 and LLVM 3.8.0.

These what you're seeing?

https://github.com/ldc-developers/ldc/issues/1463

I don't know how Travis CI isn't hitting those.

On 30.04.2016 17:48, Joakim wrote:
> On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:
>>
>>
>> On 03.04.2016 18:59, David Nadlinger via digitalmars-d-ldc wrote:
>>> [...]
>>
>> I've pushed a number of changes to the merge-2.071 branch, with the
>> result
>>
>> - appveyor Windows x64 passes
>> - appveyor Windows x86 fails for the same test as master, but I cannot
>> reproduce it locally
>> - travis OSX passes
>> - travis/circleCI linux fail for 1 unittest, and crash for 2 more
>>
>> I tried to reproduce the latter in a VM with Ubuntu 16, but also got
>> failures for the master branch. Are there known issues with special
>> configurations? I'm building with LLVM 3.7.1 and LDC 0.17.1 based on
>> DMD 2.068.2 and LLVM 3.8.0.
>
> These what you're seeing?
>
> https://github.com/ldc-developers/ldc/issues/1463
>
> I don't know how Travis CI isn't hitting those.

Yes, these are the same failures. I have only investigated std.datetime a bit, though.

On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:
>
>
> On 30.04.2016 17:48, Joakim wrote:
>> On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>> These what you're seeing?
>>
>> https://github.com/ldc-developers/ldc/issues/1463
>>
>> I don't know how Travis CI isn't hitting those.
>
> Yes, these are the same failures. I have only investigated std.datetime a bit, though.

Alright, I'm not going nuts: if I swap in the libdruntime-ldc.a from the beta1 release, all three modules pass.  Now to find out why the official beta1 druntime is different from the one I'm compiling, despite using the same source...

On 30.04.2016 19:52, Joakim wrote:
> On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:
>>
>>
>> On 30.04.2016 17:48, Joakim wrote:
>>> On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:
>>>> [...]
>>>
>>> These what you're seeing?
>>>
>>> https://github.com/ldc-developers/ldc/issues/1463
>>>
>>> I don't know how Travis CI isn't hitting those.
>>
>> Yes, these are the same failures. I have only investigated
>> std.datetime a bit, though.
>
> Alright, I'm not going nuts: if I swap in the libdruntime-ldc.a from the
> beta1 release, all three modules pass.  Now to find out why the official
> beta1 druntime is different from the one I'm compiling, despite using
> the same source...

I just noticed that the std.datetime problem disappears when disabling the garbage collection. My guess is that TLS is not scanned correctly.

The other crashing tests have longer run time, too, so I suspect they are hit by the same problem.

On 30.04.2016 20:14, Rainer Schuetze wrote:
>
>
> On 30.04.2016 19:52, Joakim wrote:
>> On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 30.04.2016 17:48, Joakim wrote:
>>>> On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:
>>>>> [...]
>>>>
>>>> These what you're seeing?
>>>>
>>>> https://github.com/ldc-developers/ldc/issues/1463
>>>>
>>>> I don't know how Travis CI isn't hitting those.
>>>
>>> Yes, these are the same failures. I have only investigated
>>> std.datetime a bit, though.
>>
>> Alright, I'm not going nuts: if I swap in the libdruntime-ldc.a from the
>> beta1 release, all three modules pass.  Now to find out why the official
>> beta1 druntime is different from the one I'm compiling, despite using
>> the same source...
>
> I just noticed that the std.datetime problem disappears when disabling
> the garbage collection. My guess is that TLS is not scanned correctly.
>

I think I have figured this out: TLS of the main thread is scanned misaligned if the size of TLS is not a multiple of the pointer size: https://github.com/ldc-developers/druntime/commit/740c1bb86b36725cf2d671a7ac8f77de692899be

On Sunday, 1 May 2016 at 08:01:42 UTC, Rainer Schuetze wrote:
>
>
> On 30.04.2016 20:14, Rainer Schuetze wrote:
>>
>>
>> On 30.04.2016 19:52, Joakim wrote:
>>> On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:
>>>>
>>>>
>>>> On 30.04.2016 17:48, Joakim wrote:
>>>>> [...]
>>>>
>>>> Yes, these are the same failures. I have only investigated
>>>> std.datetime a bit, though.
>>>
>>> Alright, I'm not going nuts: if I swap in the libdruntime-ldc.a from the
>>> beta1 release, all three modules pass.  Now to find out why the official
>>> beta1 druntime is different from the one I'm compiling, despite using
>>> the same source...
>>
>> I just noticed that the std.datetime problem disappears when disabling
>> the garbage collection. My guess is that TLS is not scanned correctly.
>>
>
> I think I have figured this out: TLS of the main thread is scanned misaligned if the size of TLS is not a multiple of the pointer size: https://github.com/ldc-developers/druntime/commit/740c1bb86b36725cf2d671a7ac8f77de692899be

Yeah, that fixes the phobos tests for me, guess it should be uncommented in getTLSRange below, still two unrelated failures in the dmd test suite.  I don't know how using druntime from the beta1 binary release didn't show this issue though.