www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - merge-2.069 now builds (and passes most of) the test suite

reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
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
parent David Nadlinger <code klickverbot.at> writes:
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
prev sibling next sibling parent kink <noone nowhere.com> writes:
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 bugs
Very nice, thx guys!
Feb 04 2016
prev sibling next sibling parent Johan Engelen <j j.nl> writes:
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
prev sibling next sibling parent reply David Nadlinger <code klickverbot.at> writes:
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
parent reply Johan Engelen <j j.nl> writes:
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
parent reply Johan Engelen <j j.nl> writes:
All green!

https://travis-ci.org/ldc-developers/ldc/builds/109326006
Feb 15 2016
next sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 15 Feb 2016, at 14:02, Johan Engelen via digitalmars-d-ldc wrote:
 All green!

 https://travis-ci.org/ldc-developers/ldc/builds/109326006
Nice! 2.070 has only a couple more failures as well, so that should be quick to fix. — David
Feb 15 2016
prev sibling parent reply kinke <noone nowhere.com> writes:
On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen wrote:
 All green!

 https://travis-ci.org/ldc-developers/ldc/builds/109326006
Very nice. Win64 still needs some love though... :)
Feb 15 2016
parent reply Johan Engelen <j j.nl> writes:
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:
 All green!

 https://travis-ci.org/ldc-developers/ldc/builds/109326006
Very nice. Win64 still needs some love though... :)
Green green green! https://ci.appveyor.com/project/kinke/ldc/build/1.0.891
Feb 18 2016
parent reply Kai Nacke <kai redstar.de> writes:
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:
 On Monday, 15 February 2016 at 13:02:41 UTC, Johan Engelen 
 wrote:
 All green!

 https://travis-ci.org/ldc-developers/ldc/builds/109326006
Very nice. Win64 still needs some love though... :)
Green green green! https://ci.appveyor.com/project/kinke/ldc/build/1.0.891
This really rocks. The next alpha version of ldc is not too far away!!! Regards, Kai
Feb 18 2016
next sibling parent Johan Engelen <j j.nl> writes:
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
prev sibling parent reply kinke <noone nowhere.com> writes:
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
parent reply Dan Olson <gorox comcast.net> writes:
kinke <noone nowhere.com> writes:

 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! :)
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? -- Dan
Feb 21 2016
next sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
parent Kai Nacke <kai redstar.de> writes:
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:
 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
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, Kai
Feb 21 2016
prev sibling parent reply kink <noone nowhere.com> writes:
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
parent reply Dan Olson <gorox comcast.net> writes:
kink <noone nowhere.com> writes:

 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.
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. -- Dan
Feb 23 2016
parent kinke <noone nowhere.com> writes:
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
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
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
parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Dan Olson <gorox concast.net> writes:
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:

 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?
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. Dan
Feb 18 2016
parent reply Jacob Carlborg <doob me.com> writes:
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
parent Dan Olson <gorox comcast.net> writes:
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