digitalmars.D.ldc - merge-2.069 now builds (and passes most of) the test suite
- David Nadlinger via digitalmars-d-ldc (30/30) Feb 03 2016 Hi all,
- Joakim (9/38) Feb 03 2016 Great news! I was hoping the D frontend merge wouldn't take that
- David Nadlinger (8/14) Feb 03 2016 Quite normal, unfortunately, since the AST semantics tend to
- kink (3/6) Feb 04 2016 Very nice, thx guys!
- Johan Engelen (7/13) Feb 04 2016 Great!
- David Nadlinger (4/4) Feb 07 2016 The only remaining failures are a few dmd-testsuite test cases
- Johan Engelen (8/10) Feb 14 2016 The only remaining issue is "-cov" on Linux (it works fine on OS
- Johan Engelen (2/2) Feb 15 2016 All green!
- David Nadlinger via digitalmars-d-ldc (4/6) Feb 15 2016 Nice!
- kinke (2/4) Feb 15 2016 Very nice. Win64 still needs some love though... :)
- Johan Engelen (3/9) Feb 18 2016 Green green green!
- Kai Nacke (6/16) Feb 18 2016 This really rocks. The next alpha version of ldc is not too far
- Johan Engelen (5/5) Feb 18 2016 LDC 0.17.0 builds merge-2.069
- kinke (6/8) Feb 21 2016 I think the time would be right to merge-2.069 into master. We're
- Dan Olson (9/16) Feb 21 2016 Once this happens, need to pick a branch for actively maintaining and
- David Nadlinger via digitalmars-d-ldc (4/6) Feb 21 2016 Yep, I agree. I was thinking Kai would just create the branch when (or
- Kai Nacke (9/16) Feb 21 2016 Hi,
- kink (4/6) Feb 22 2016 I'm hoping we'll soon put more focus on cross-compilability and
- Jacob Carlborg (4/7) Feb 18 2016 Is the Objective-C supported implemented?
- David Nadlinger via digitalmars-d-ldc (9/10) Feb 18 2016 Unfortunately, ObjC support is not implemented in master right now.
- Jacob Carlborg (7/12) Feb 18 2016 I kind of know what needs to be done, but I would not know how to do it
- Dan Olson (7/25) Feb 18 2016 I might be able to help once I get done with arm-linux. Last
- Jacob Carlborg (47/51) Feb 19 2016 It's only external classes and instance methods that are implemented so
- Dan Olson (93/100) Feb 20 2016 It's a good description and I am excited to get it working!
Hi all, Thanks to Johan Engelen's awesome work, the first usable LDC version with a D-based frontend is inching closer and closer. There is still much left to be done, as it is in the aftermath of every frontend merge. But I've fixed some of the most severe bugs, and the test suite runners are up and running now again: --- The following tests FAILED: 242 - std.math (Failed) 243 - std.datetime (Failed) 253 - std.zip (Failed) 262 - std.string (Failed) 267 - std.uni (Failed) 321 - std.net.curl (SEGFAULT) 329 - std.regex.internal.tests (SEGFAULT) 603 - std.math-debug (Failed) 604 - std.datetime-debug (Failed) 614 - std.zip-debug (Failed) 623 - std.string-debug (Failed) 682 - std.net.curl-debug (SEGFAULT) 687 - std.regex-debug (SEGFAULT) 690 - std.regex.internal.tests-debug (SEGFAULT) 732 - dmd-testsuite-debug (Failed) 734 - dmd-testsuite (Failed) --- The current state is available from the "merge-2.069" branch on ldc-developers/ldc. For now, you might want to use DMD to build the frontend parts still, as there appears to be a C++ ABI bug affecting it in LDC still. — David
Feb 03 2016
On Thursday, 4 February 2016 at 03:36:14 UTC, David Nadlinger wrote:Hi all, Thanks to Johan Engelen's awesome work, the first usable LDC version with a D-based frontend is inching closer and closer. There is still much left to be done, as it is in the aftermath of every frontend merge. But I've fixed some of the most severe bugs, and the test suite runners are up and running now again: --- The following tests FAILED: 242 - std.math (Failed) 243 - std.datetime (Failed) 253 - std.zip (Failed) 262 - std.string (Failed) 267 - std.uni (Failed) 321 - std.net.curl (SEGFAULT) 329 - std.regex.internal.tests (SEGFAULT) 603 - std.math-debug (Failed) 604 - std.datetime-debug (Failed) 614 - std.zip-debug (Failed) 623 - std.string-debug (Failed) 682 - std.net.curl-debug (SEGFAULT) 687 - std.regex-debug (SEGFAULT) 690 - std.regex.internal.tests-debug (SEGFAULT) 732 - dmd-testsuite-debug (Failed) 734 - dmd-testsuite (Failed) ---Great news! I was hoping the D frontend merge wouldn't take that long. Is it normal for phobos tests to be failing on a merge, ie even when the frontend was C++?The current state is available from the "merge-2.069" branch on ldc-developers/ldc. For now, you might want to use DMD to build the frontend parts still, as there appears to be a C++ ABI bug affecting it in LDC still.Hmm, I was hoping to build ldc 2.069 on ARM too, which will require using ldc to compile the D frontend to ARM. I thought dmd upstream builds fine with ldc, is this something different from the bug that build had before?
Feb 03 2016
On Thursday, 4 February 2016 at 04:47:52 UTC, Joakim wrote:Is it normal for phobos tests to be failing on a merge, ie even when the frontend was C++?Quite normal, unfortunately, since the AST semantics tend to silently change from time to time.Hmm, I was hoping to build ldc 2.069 on ARM too, which will require using ldc to compile the D frontend to ARM. I thought dmd upstream builds fine with ldc, is this something different from the bug that build had before?All I can say is that it blew up quite more spectacularly with LDC at first than with DMD – it might be an OS X-only issue, though, since I didn't have time to go back to trying another LDC/LDC build yet. — David
Feb 03 2016
On Thursday, 4 February 2016 at 03:36:14 UTC, David Nadlinger wrote:Thanks to Johan Engelen's awesome work [...] I've fixed some of the most severe bugsVery nice, thx guys!
Feb 04 2016
On Thursday, 4 February 2016 at 03:36:14 UTC, David Nadlinger wrote:I've fixed some of the most severe bugs, and the test suite runners are up and running now again:Great!The current state is available from the "merge-2.069" branch on ldc-developers/ldc. For now, you might want to use DMD to build the frontend parts still, as there appears to be a C++ ABI bug affecting it in LDC still.Sounds like something fun I can work on after I´m back from vacation :) cheers, Johan
Feb 04 2016
The only remaining failures are a few dmd-testsuite test cases and std.{string, uni}. I'll leave it at that for now so Johan can have some fun, too. ;) — David
Feb 07 2016
On Sunday, 7 February 2016 at 19:58:28 UTC, David Nadlinger wrote:The only remaining failures are a few dmd-testsuite test cases and std.{string, uni}.The only remaining issue is "-cov" on Linux (it works fine on OS X), so we already have a few green marks on Travis! https://travis-ci.org/ldc-developers/ldc/builds/109185087 kinke, Could you install DMD on AppVeyor? Thanks! https://ci.appveyor.com/project/kinke/ldc/build/1.0.874/job/0kdaehw73stq16hp (locally on my Windows machine, things already work with default installed DMD)
Feb 14 2016
All green! https://travis-ci.org/ldc-developers/ldc/builds/109326006
Feb 15 2016
On 15 Feb 2016, at 14:02, Johan Engelen via digitalmars-d-ldc wrote:All green! https://travis-ci.org/ldc-developers/ldc/builds/109326006Nice! 2.070 has only a couple more failures as well, so that should be quick to fix. — David
Feb 15 2016
On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:All green! https://travis-ci.org/ldc-developers/ldc/builds/109326006Very nice. Win64 still needs some love though... :)
Feb 15 2016
On Monday, 15 February 2016 at 22:04:51 UTC, kinke wrote:On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:Green green green! https://ci.appveyor.com/project/kinke/ldc/build/1.0.891All green! https://travis-ci.org/ldc-developers/ldc/builds/109326006Very nice. Win64 still needs some love though... :)
Feb 18 2016
On Thursday, 18 February 2016 at 10:52:47 UTC, Johan Engelen wrote:On Monday, 15 February 2016 at 22:04:51 UTC, kinke wrote:This really rocks. The next alpha version of ldc is not too far away!!! Regards, KaiOn Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:Green green green! https://ci.appveyor.com/project/kinke/ldc/build/1.0.891All green! https://travis-ci.org/ldc-developers/ldc/builds/109326006Very nice. Win64 still needs some love though... :)
Feb 18 2016
LDC 0.17.0 builds merge-2.069 without issues on Travis: https://travis-ci.org/ldc-developers/ldc/builds/110114415 waiting for result on AppVeyor: https://ci.appveyor.com/project/kinke/ldc/build/1.0.902
Feb 18 2016
On Thursday, 18 February 2016 at 11:49:15 UTC, Kai Nacke wrote:This really rocks. The next alpha version of ldc is not too far away!!!I think the time would be right to merge-2.069 into master. We're green on Travis and AppVeyor, David's apparently already experimenting on merge-2.070 ;), and existing PRs shouldn't be that hard to rebase. Great job guys! :)
Feb 21 2016
kinke <noone nowhere.com> writes:On Thursday, 18 February 2016 at 11:49:15 UTC, Kai Nacke wrote:Once this happens, need to pick a branch for actively maintaining and enhancing the 0.17.x line with C++ frontend. It will be the bootstrap D compiler for all those non-x86 platforms. Seems like it should be something like ldc-0.17. All pending arm-linux changes will need to go there too. Kai, David? -- DanThis really rocks. The next alpha version of ldc is not too far away!!!I think the time would be right to merge-2.069 into master. We're green on Travis and AppVeyor, David's apparently already experimenting on merge-2.070 ;), and existing PRs shouldn't be that hard to rebase. Great job guys! :)
Feb 21 2016
On 22 Feb 2016, at 0:18, Dan Olson via digitalmars-d-ldc wrote:Once this happens, need to pick a branch for actively maintaining and enhancing the 0.17.x line with C++ frontend.Yep, I agree. I was thinking Kai would just create the branch when (or rather, before) he merges 2.069 to master. — David
Feb 21 2016
On Sunday, 21 February 2016 at 23:31:39 UTC, David Nadlinger wrote:On 22 Feb 2016, at 0:18, Dan Olson via digitalmars-d-ldc wrote:Hi, that was my plan for the Weekend. Unfortunately it was delayed by some Trouble with my Notebook... I like to do it today, including creating a tag for the alpha version. Regards, KaiOnce this happens, need to pick a branch for actively maintaining and enhancing the 0.17.x line with C++ frontend.Yep, I agree. I was thinking Kai would just create the branch when (or rather, before) he merges 2.069 to master. — David
Feb 21 2016
On Sunday, 21 February 2016 at 23:18:32 UTC, Dan Olson wrote:It will be the bootstrap D compiler for all those non-x86 platforms.I'm hoping we'll soon put more focus on cross-compilability and thus not have to rely on such a bootstrap compiler. But until then we need a purely C++ one, that's right.
Feb 22 2016
kink <noone nowhere.com> writes:On Sunday, 21 February 2016 at 23:18:32 UTC, Dan Olson wrote:I'm thinking more the non-embedded platforms, ones that you development on and for. Like the Rasperberry Pi. I think those will always be easier to bootstrap than to try and cross-compile LDC and LLVM. -- DanIt will be the bootstrap D compiler for all those non-x86 platforms.I'm hoping we'll soon put more focus on cross-compilability and thus not have to rely on such a bootstrap compiler. But until then we need a purely C++ one, that's right.
Feb 23 2016
On Tuesday, 23 February 2016 at 16:52:18 UTC, Dan Olson wrote:I'm thinking more the non-embedded platforms, ones that you development on and for. Like the Rasperberry Pi. I think those will always be easier to bootstrap than to try and cross-compile LDC and LLVM.I was thinking about only cross-compiling the ddmd front-end. Compiling the C++ parts of LDC and then linking all object files against a native LLVM on the target platform is surely the simpler approach. So all one would need for bootstrapping is a LDC binary on an already supported platform with an LLVM able to output object files for the target. And some more CMake magic of course. ;)
Feb 26 2016
On 2016-02-04 04:36, David Nadlinger via digitalmars-d-ldc wrote:Hi all, Thanks to Johan Engelen's awesome work, the first usable LDC version with a D-based frontend is inching closer and closer.Is the Objective-C supported implemented? -- /Jacob Carlborg
Feb 18 2016
Hi Jacob, On 18 Feb 2016, at 21:00, Jacob Carlborg via digitalmars-d-ldc wrote:Is the Objective-C supported implemented?Unfortunately, ObjC support is not implemented in master right now. I haven't had a look at what this would entail myself yet. If you can spare some time, your help with that would be very much appreciated, since most of us would probably have to reverse-engineer the DMD implementation first. Best David
Feb 18 2016
On 2016-02-18 21:07, David Nadlinger via digitalmars-d-ldc wrote:Unfortunately, ObjC support is not implemented in master right now. I haven't had a look at what this would entail myself yet. If you can spare some time, your help with that would be very much appreciated, since most of us would probably have to reverse-engineer the DMD implementation first.I kind of know what needs to be done, but I would not know how to do it in LDC. It was hard enough to figure out how to do it in DMD. What would be the best way? That I describe how it works and a LDC developer implements it. Or do I need to implement it myself? -- /Jacob Carlborg
Feb 18 2016
On Thursday, 18 February 2016 at 21:09:27 UTC, Jacob Carlborg wrote:On 2016-02-18 21:07, David Nadlinger via digitalmars-d-ldc wrote:I might be able to help once I get done with arm-linux. Last summer for fun I started integrating your older fully functional obj-d branch with ldc. I got instance method calls and selectors working, although the code was very much a kludge. DanUnfortunately, ObjC support is not implemented in master right now. I haven't had a look at what this would entail myself yet. If you can spare some time, your help with that would be very much appreciated, since most of us would probably have to reverse-engineer the DMD implementation first.I kind of know what needs to be done, but I would not know how to do it in LDC. It was hard enough to figure out how to do it in DMD. What would be the best way? That I describe how it works and a LDC developer implements it. Or do I need to implement it myself?
Feb 18 2016
On 2016-02-19 02:04, Dan Olson wrote:I might be able to help once I get done with arm-linux.Ok, cool.Last summer for fun I started integrating your older fully functional obj-d branch with ldc. I got instance method calls and selectors working, although the code was very much a kludge.It's only external classes and instance methods that are implemented so far in upstream DMD. The commit message for the commit [1] that implements the support contains some explanation on how it works. The explanation is pretty high level and doesn't explain the data layout in the object files. I included the commit message here for convince: ================ Commit Message ================ Basic support for classes, interfaces and instance methods. This is implemented by adding a new linkage attribute, `Objective-C`, and a compiler recognized UDA, ` selector`. The linkage attribute is to be used on a class or interface. The UDA is attached to a method. The linkage attribute tells the compiler that the class should use the name mangling that matches the one used by Objective-C (same as C, no mangling) and that all methods in the class should use the Objective-C way of calling methods, see below. The calling convention for Objective-C methods and functions is the same as for C. The selector UDA tells the compiler what Objective-C selector the method should have. The selector is used in the Objective-C runtime to find the implementation of a given method. An Objective-C method call is implemented by making a regular C call to the `objc_msgSend` function in the Objective-C runtime. The signature of `objc_msgSend` looks something like this: `id objc_msgSend(id self, SEL op, ...);` * The first parameter is the object (this/self pointer) * The second parameter is the selector attached to the method * The last parameter is for all the arguments that the implementation expects The call to `objc_msgSend` should not be performed as a variadic call but instead as if it had the same signature as the method that should be called but with the two additional parameter, `self` and `op`, added first. The implementation of `objc_msgSend` will jump to the method instead of calling it. Because of the above, multiple versions exist of `objc_msgSend`. Depending on the return type of the method that is called the correct version need to be used. This depends on the ABI. This is a list of functions and for which types they're used on OS X 64bit: * objc_msgSend_stret - Used for structs too large to be returned in registries * objc_msgSend_fpret - Used for `long double` * objc_msgSend_fp2ret - Used for `_Complex long double` * objc_msgSend - Used for everything else [1] 867d5479b6d98b23b6c797ee487d1ec1474bee10 -- /Jacob Carlborg
Feb 19 2016
Jacob Carlborg <doob me.com> writes:On 2016-02-19 02:04, Dan Olson wrote: It's only external classes and instance methods that are implemented so far in upstream DMD.I think I had most of that working, but I'll have to review my old work.The commit message for the commit [1] that implements the support contains some explanation on how it works. The explanation is pretty high level and doesn't explain the data layout in the object files. I included the commit message here for convince:It's a good description and I am excited to get it working! I looked back and I stopped working on integrating your branch with LDC in Aug 2015. I think that was when I realized there were darwin ABI problems with return structs like struct PointF {float x, y;} and worked on that instead. Here was my last test file, with an example of what seemed to work. There was a companion mainm.m file that defined MyClass and called dcall(). import objc.types; struct PointF { float x, y; } struct PointR { real x, y; } extern (Objective-C) class MyClass : NSObject { int xyzzy; void funAtPointF(int i, PointF p) selector("fun:atPointF:"); void fun(int i) selector("fun:"); void fun(int a,int b) selector("fun:and:"); void foo(); // selector("foo"); int ifoo() selector("ifoo"); float ffoo() selector("ffoo"); double dfoo() selector("dfoo"); real rfoo() selector("rfoo"); creal crfoo() selector("crfoo"); PointF pfoo() selector("pfoo"); PointR prfoo() selector("prfoo"); } extern(C) int printf(const char*, ...); extern(C) int dcall(MyClass c) { c.fun(42); c.fun(10, 1); c.funAtPointF(42, PointF(13,99)); c.foo(); auto i = c.ifoo(); printf("%d\n", i); auto f = c.ffoo(); printf("%f\n", f); auto d = c.dfoo(); printf("%f\n", d); auto r = c.rfoo(); printf("%Lf\n", r); //auto cr = c.crfoo(); auto p = c.pfoo(); printf("%g %g\n", p.x, p.y); auto pr = c.prfoo(); printf("%Lg %Lg\n", pr.x, pr.y); void __selector(int) funSel = &MyClass.fun; funSel(c, 42); void __selector(int,int) funAndSel = &MyClass.fun; funAndSel(c, 1,10); auto funAtPointFSel = &MyClass.funAtPointF; //void __selector(int,PointF) funAtPointFSel = &MyClass.funAtPointF; funAtPointFSel(c, 101, PointF(1.5, 3.125)); void __selector() fooSel = &MyClass.foo; fooSel(c); int __selector() ifooSel = &MyClass.ifoo; return ifooSel(c); } Output looked like this: $ build/bin/ldc2 classd.d -c $ cc mainm.m classd.o build/lib/libdruntime-ldc.a -lobjc $ ./a.out fun(42) fun(10,1) fun(42, PointF(13,99)) foo() 42 <- ifoo() 42 42 <- ffoo() 42.000000 42 <- dfoo() 42.000000 42 <- rfoo() 42.000000 42,2112 <- pfoo() 42 2112 42,2112 <- prfoo() 42 2112 fun(42) fun(1,10) fun(101, PointF(1.5,3.125)) foo() 42 <- ifoo() dcall returned 42 -- Dan
Feb 20 2016