digitalmars.D.ldc - master now at 2.070, merge-2.071 branch created
- David Nadlinger via digitalmars-d-ldc (21/21) Apr 03 2016 Hi all,
- Temtaime (3/26) Apr 03 2016 Grats !
- Kai Nacke (5/26) Apr 03 2016 Really great. :-)
- Rainer Schuetze (14/19) Apr 30 2016 I've pushed a number of changes to the merge-2.071 branch, with the resu...
- Joakim (4/19) Apr 30 2016 These what you're seeing?
- Rainer Schuetze (3/25) Apr 30 2016 Yes, these are the same failures. I have only investigated std.datetime
- Joakim (5/17) Apr 30 2016 Alright, I'm not going nuts: if I swap in the libdruntime-ldc.a
- Rainer Schuetze (5/24) Apr 30 2016 I just noticed that the std.datetime problem disappears when disabling
- Rainer Schuetze (4/27) May 01 2016 I think I have figured this out: TLS of the main thread is scanned
- Joakim (5/36) May 01 2016 Yeah, that fixes the phobos tests for me, guess it should be
- Rainer Schuetze (10/25) May 02 2016 Please note that the versioned code in getTLSRange aligns to
- Joakim (4/17) May 02 2016 Yeah, ran into those when I tried it: I simply copied and pasted
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
Apr 03 2016
Temtaime <temtaime gmail.com> 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, DavidGrats ! It's amazing
Apr 03 2016
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
Apr 03 2016
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 ;-)
Apr 30 2016
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:These what you're seeing? https://github.com/ldc-developers/ldc/issues/1463 I don't know how Travis CI isn't hitting those.[...]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.
Apr 30 2016
On 30.04.2016 17:48, Joakim wrote:On Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:Yes, these are the same failures. I have only investigated std.datetime a bit, though.On 03.04.2016 18:59, David Nadlinger via digitalmars-d-ldc 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.[...]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.
Apr 30 2016
On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:On 30.04.2016 17:48, Joakim wrote: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 Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:Yes, these are the same failures. I have only investigated std.datetime a bit, though.[...]These what you're seeing? https://github.com/ldc-developers/ldc/issues/1463 I don't know how Travis CI isn't hitting those.
Apr 30 2016
On 30.04.2016 19:52, Joakim wrote:On Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote: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 17:48, Joakim wrote: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 Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:Yes, these are the same failures. I have only investigated std.datetime a bit, though.[...]These what you're seeing? https://github.com/ldc-developers/ldc/issues/1463 I don't know how Travis CI isn't hitting those.
Apr 30 2016
On 30.04.2016 20:14, Rainer Schuetze wrote:On 30.04.2016 19:52, Joakim wrote: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/740c1bb86b36725cf2d671a7ac8f77de692899beOn Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:I just noticed that the std.datetime problem disappears when disabling the garbage collection. My guess is that TLS is not scanned correctly.On 30.04.2016 17:48, Joakim wrote: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 Saturday, 30 April 2016 at 15:32:15 UTC, Rainer Schuetze wrote:Yes, these are the same failures. I have only investigated std.datetime a bit, though.[...]These what you're seeing? https://github.com/ldc-developers/ldc/issues/1463 I don't know how Travis CI isn't hitting those.
May 01 2016
On Sunday, 1 May 2016 at 08:01:42 UTC, Rainer Schuetze wrote:On 30.04.2016 20:14, Rainer Schuetze wrote: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.On 30.04.2016 19:52, Joakim wrote: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/740c1bb86b36725cf2d671a7ac8f77de692899beOn Saturday, 30 April 2016 at 16:06:13 UTC, Rainer Schuetze wrote:I just noticed that the std.datetime problem disappears when disabling the garbage collection. My guess is that TLS is not scanned correctly.On 30.04.2016 17:48, Joakim wrote: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...[...]Yes, these are the same failures. I have only investigated std.datetime a bit, though.
May 01 2016
On 01.05.2016 23:54, Joakim wrote:On Sunday, 1 May 2016 at 08:01:42 UTC, Rainer Schuetze wrote:Please note that the versioned code in getTLSRange aligns to 2*size_t.sizeof which seems to relate to something else. Actually I added the alignment there first, but it triggered assertions elsewhere which would have to be adjusted, too. Aligning the stored size was the smallest change.Yeah, that fixes the phobos tests for me, guess it should be uncommented in getTLSRange below,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/740c1bb86b36725cf2d671a7ac8f77de692899bestill 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.It very much depends on the size and alignment of the last element in the TLS section. The order of symbol placement probably depends on order of object files in library, order of command line arguments, symbol dependencies and more, so pretty hard to predict.
May 02 2016
On Monday, 2 May 2016 at 07:08:13 UTC, Rainer Schuetze wrote:On 01.05.2016 23:54, Joakim wrote:Yeah, ran into those when I tried it: I simply copied and pasted the adjustment before the assertion too.[...]Please note that the versioned code in getTLSRange aligns to 2*size_t.sizeof which seems to relate to something else. Actually I added the alignment there first, but it triggered assertions elsewhere which would have to be adjusted, too. Aligning the stored size was the smallest change.OK, good to know, thanks for fixing it.[...]It very much depends on the size and alignment of the last element in the TLS section. The order of symbol placement probably depends on order of object files in library, order of command line arguments, symbol dependencies and more, so pretty hard to predict.
May 02 2016