www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Master is now at frontend level 2.069.2

reply Kai Nacke <kai redstar.de> writes:
Hi everyone!

I merged the merge-2.069 branch into master right now. We are 
approaching the next release very fast!

Because the frontend is now written in D we Need a D Compiler to 
bootstrap. I moved the previous master to branch ltsmaster. This 
is the branch where we continue to maintain the C++ based version 
of LDC (release 0.17.x).

Have fun!

Regards,
Kai
Feb 22 2016
next sibling parent reply Dan Olson <gorox comcast.net> writes:
Kai Nacke <kai redstar.de> writes:

 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler to
 bootstrap. I moved the previous master to branch ltsmaster. This is
 the branch where we continue to maintain the C++ based version of LDC
 (release 0.17.x).

 Have fun!

 Regards,
 Kai
Nice and thanks. I assume best practice for changes intended for both ltsmaster and master, do pull-request to ltsmaster first, then later merge into master? I am thinking of my latest arm-linux changes. And "ltsmaster" - what does "lts" stand for? -- Dan
Feb 23 2016
next sibling parent reply kink <noone nowhere.com> writes:
On Tuesday, 23 February 2016 at 16:59:25 UTC, Dan Olson wrote:
 And "ltsmaster" - what does "lts" stand for?
Long-term support I'd guess (known from Ubuntu).
Feb 23 2016
parent Kai Nacke <kai redstar.de> writes:
On Tuesday, 23 February 2016 at 17:02:45 UTC, kink wrote:
 On Tuesday, 23 February 2016 at 16:59:25 UTC, Dan Olson wrote:
 And "ltsmaster" - what does "lts" stand for?
Long-term support I'd guess (known from Ubuntu).
Right, I copied the Ubuntu term. I did not want to include a version number and chose this generic term. Regards, Kai
Feb 23 2016
prev sibling parent reply Kai Nacke <kai redstar.de> writes:
On Tuesday, 23 February 2016 at 16:59:25 UTC, Dan Olson wrote:
 Kai Nacke <kai redstar.de> writes:

 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).
Nice and thanks. I assume best practice for changes intended for both ltsmaster and master, do pull-request to ltsmaster first, then later merge into master? I am thinking of my latest arm-linux changes.
Hi Dan! This is the process we need to follow. All target architecture relevant changes (ARM, AArch64, etc.), LLVM updates and maybe bug fixes (#1224, #1292) should be developed first for ltsmaster. Regards, Kai
Feb 23 2016
parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 23 February 2016 at 20:11:42 UTC, Kai Nacke wrote:
 On Tuesday, 23 February 2016 at 16:59:25 UTC, Dan Olson wrote:
 Nice and thanks.  I assume best practice for changes intended 
 for both ltsmaster and master, do pull-request to ltsmaster 
 first, then later merge into master?  I am thinking of my 
 latest arm-linux changes.
Hi Dan! This is the process we need to follow. All target architecture relevant changes (ARM, AArch64, etc.), LLVM updates and maybe bug fixes (#1224, #1292) should be developed first for ltsmaster.
Isn't the opposite usually done? Develop something for master, and backport to LTS ? (perhaps less chance of introducing something bad in LTS?)
Feb 23 2016
parent Kai Nacke <kai redstar.de> writes:
On Tuesday, 23 February 2016 at 20:40:36 UTC, Johan Engelen wrote:
 On Tuesday, 23 February 2016 at 20:11:42 UTC, Kai Nacke wrote:
 On Tuesday, 23 February 2016 at 16:59:25 UTC, Dan Olson wrote:
 Nice and thanks.  I assume best practice for changes intended 
 for both ltsmaster and master, do pull-request to ltsmaster 
 first, then later merge into master?  I am thinking of my 
 latest arm-linux changes.
Hi Dan! This is the process we need to follow. All target architecture relevant changes (ARM, AArch64, etc.), LLVM updates and maybe bug fixes (#1224, #1292) should be developed first for ltsmaster.
Isn't the opposite usually done? Develop something for master, and backport to LTS ? (perhaps less chance of introducing something bad in LTS?)
We should also not break the master branch. I view it from the practically side: I develop against ltsmaster and can then merge the changes into master. Otherwise I need to cherry-pick the commit which is always a bit clumsy. Regards, Kai
Feb 23 2016
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).

 Have fun!

 Regards,
 Kai
The speed of development of LDC is impressive, thank you Kai/LDC team.
Feb 23 2016
next sibling parent Kai Nacke <kai redstar.de> writes:
On Wednesday, 24 February 2016 at 05:25:33 UTC, rsw0x wrote:
 On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).

 Have fun!

 Regards,
 Kai
The speed of development of LDC is impressive, thank you Kai/LDC team.
Thanks. It is the team which is doing the work behind the scenes. I currently only create the releases and write the announcements... Regards, Kai
Feb 23 2016
prev sibling parent reply Russel Winder via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On Wed, 2016-02-24 at 05:25 +0000, rsw0x via digitalmars-d-ldc wrote:
 [=E2=80=A6]
 The speed of development of LDC is impressive, thank you Kai/LDC=C2=A0
 team.
Here, here. ldc2 is definitely my D compiler of choice. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 24 2016
parent Kai Nacke <kai redstar.de> writes:
On Wednesday, 24 February 2016 at 08:07:38 UTC, Russel Winder 
wrote:
 On Wed, 2016-02-24 at 05:25 +0000, rsw0x via digitalmars-d-ldc 
 wrote:
 […]
 The speed of development of LDC is impressive, thank you 
 Kai/LDC
 team.
Here, here. ldc2 is definitely my D compiler of choice.
Thanks!
Feb 24 2016
prev sibling next sibling parent reply Suliman <evermind live.ru> writes:
On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).

 Have fun!

 Regards,
 Kai
Next version will be 1.0?
Feb 23 2016
parent reply Kai Nacke <kai redstar.de> writes:
On Wednesday, 24 February 2016 at 06:24:58 UTC, Suliman wrote:
 On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).

 Have fun!

 Regards,
 Kai
Next version will be 1.0?
Hi Suliman! Yes, next version will be 1.0. This was discussed earlier in this forum. The move to the D based frontend is a major milestone for this project. Given the current shape of the project and the development activity right now, we are really ready for a 1.0 version. :-) Regards, Kai
Feb 23 2016
parent reply Russel Winder via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On Wed, 2016-02-24 at 07:41 +0000, Kai Nacke via digitalmars-d-ldc
wrote:
=20
[=E2=80=A6]
 Yes, next version will be 1.0. This was discussed earlier in this=C2=A0
 forum.
 The move to the D based frontend is a major milestone for this=C2=A0
 project.
 Given the current shape of the project and the development=C2=A0
 activity right now, we are really ready for a 1.0 version. :-)
Go to LDC 1.0 with D 2.069 or with D 2.070? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 24 2016
parent reply Kai Nacke <kai redstar.de> writes:
On Wednesday, 24 February 2016 at 08:08:40 UTC, Russel Winder 
wrote:
 On Wed, 2016-02-24 at 07:41 +0000, Kai Nacke via 
 digitalmars-d-ldc wrote:
 
[…]
 Yes, next version will be 1.0. This was discussed earlier in 
 this
 forum.
 The move to the D based frontend is a major milestone for this
 project.
 Given the current shape of the project and the development
 activity right now, we are really ready for a 1.0 version. :-)
Go to LDC 1.0 with D 2.069 or with D 2.070?
This is not yet decided. The 1.0.0-alpha1 release is based on D 2.069 (as I am currently building the binaries). But there is still some work required, especially for non-Intel platforms. If we manage to fix the last test failures in D 2.070 (only three!) in the meantime then the 1.0 release will be based on 2.070. Regards, Kai
Feb 24 2016
next sibling parent Johan Engelen <j j.nl> writes:
On Wednesday, 24 February 2016 at 19:29:52 UTC, Kai Nacke wrote:
 This is not yet decided. The 1.0.0-alpha1 release is based on D 
 2.069 (as I am currently building the binaries). But there is 
 still some work required, especially for non-Intel platforms.
Also, LDC master cannot build itself on Windows, which is a little embarrassing !
Feb 24 2016
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 24 February 2016 at 19:29:52 UTC, Kai Nacke wrote:
 On Wednesday, 24 February 2016 at 08:08:40 UTC, Russel Winder 
 wrote:
 On Wed, 2016-02-24 at 07:41 +0000, Kai Nacke via 
 digitalmars-d-ldc wrote:
 
[…]
 Yes, next version will be 1.0. This was discussed earlier in 
 this
 forum.
 The move to the D based frontend is a major milestone for this
 project.
 Given the current shape of the project and the development
 activity right now, we are really ready for a 1.0 version. :-)
Go to LDC 1.0 with D 2.069 or with D 2.070?
This is not yet decided. The 1.0.0-alpha1 release is based on D 2.069 (as I am currently building the binaries). But there is still some work required, especially for non-Intel platforms. If we manage to fix the last test failures in D 2.070 (only three!)
One test failure was trivial to fix, I think there is now only the druntime/object.d failure left! (we also shouldn't forget to merge-in the upcoming 2.070.1 release)
Feb 24 2016
parent Johan Engelen <j j.nl> writes:
On Wednesday, 24 February 2016 at 20:51:04 UTC, Johan Engelen 
wrote:
 One test failure was trivial to fix, I think there is now only 
 the druntime/object.d failure left!
Nope, it's like Kai said: three failures left.
Feb 24 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-02-24 20:29, Kai Nacke wrote:

 This is not yet decided. The 1.0.0-alpha1 release is based on D 2.069
 (as I am currently building the binaries). But there is still some work
 required, especially for non-Intel platforms. If we manage to fix the
 last test failures in D 2.070 (only three!) in the meantime then the 1.0
 release will be based on 2.070.
It would be nice to have the Objective-C support as well. -- /Jacob Carlborg
Feb 25 2016
prev sibling next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster.
If I'm right you should: - Compile 2.069 source with ltsmaster => tmp2.069 - Compile 2.069 source with tmp2.069 => lcd2.069 If not ldc 2.069 itself doesn't take advantage of new fixes/optimizations... tmp2.069 produces "optimized" binaries but it isn't optimized. Am I right?
Feb 25 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 25 Feb 2016, at 18:00, Andrea Fontana via digitalmars-d-ldc wrote:
 If not ldc 2.069 itself doesn't take advantage of new 
 fixes/optimizations...
 tmp2.069 produces "optimized" binaries but it isn't optimized. Am I 
 right?
You are right, in theory. I'm not sure whether there are any significant improvements in 2.069.2 though that would warrant that two-stage process at this point. — David
Feb 25 2016
parent Andrea Fontana <nospam example.com> writes:
On Thursday, 25 February 2016 at 17:11:08 UTC, David Nadlinger 
wrote:
 On 25 Feb 2016, at 18:00, Andrea Fontana via digitalmars-d-ldc 
 wrote:
 If not ldc 2.069 itself doesn't take advantage of new 
 fixes/optimizations...
 tmp2.069 produces "optimized" binaries but it isn't optimized. 
 Am I right?
You are right, in theory. I'm not sure whether there are any significant improvements in 2.069.2 though that would warrant that two-stage process at this point. — David
Anyway it could be itself a good test to compile. Andrea
Feb 26 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 23 February 2016 at 05:51:01 UTC, Kai Nacke wrote:
 Hi everyone!

 I merged the merge-2.069 branch into master right now. We are 
 approaching the next release very fast!

 Because the frontend is now written in D we Need a D Compiler 
 to bootstrap. I moved the previous master to branch ltsmaster. 
 This is the branch where we continue to maintain the C++ based 
 version of LDC (release 0.17.x).
I've been trying out the new merge branches on Arch linux/x86_64 today. The master branch and merge-2.069 have test failures in std.datetime, std.math, std.regex.internal.tests, and std.net.curl in release mode, plus the same four and std.regex in debug mode. The dmd compiler and llvm IR test suites also fail quickly. With merge-2.070, the same results plus the object module has some test failure in both modes. Other than those, everything passes. :) I haven't seen linux/x64 results mentioned and I don't think it's tested on the auto-tester: anyone else getting the same results?
Feb 25 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Joakim,

On 25 Feb 2016, at 20:06, Joakim via digitalmars-d-ldc wrote:
 I've been trying out the new merge branches on Arch linux/x86_64 
 today.
Thanks for testing!
 The master branch and merge-2.069
Just to make sure there are no misunderstandings, merge-2.069 does not exist in the upstream repo anymore, following the merge.
 I haven't seen linux/x64 results mentioned and I don't think it's 
 tested on the auto-tester: anyone else getting the same results?
All the builds on Travis are 64 bit, except for the one multilib configuration. As such, it's quite weird that you are seeing this failures. Which master commit in particular are you testing, and which LLVM version are you building against? — David
Feb 25 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 25 February 2016 at 19:19:53 UTC, David Nadlinger 
wrote:
 Hi Joakim,

 On 25 Feb 2016, at 20:06, Joakim via digitalmars-d-ldc wrote:
 I've been trying out the new merge branches on Arch 
 linux/x86_64 today.
Thanks for testing!
 The master branch and merge-2.069
Just to make sure there are no misunderstandings, merge-2.069 does not exist in the upstream repo anymore, following the merge.
OK, it still shows up in my local list of remote branches. I guess git pull won't update the list and I have to prune such deleted remote branches myself occasionally, using a command like "git remote update origin --prune," which I just found through google.
 I haven't seen linux/x64 results mentioned and I don't think 
 it's tested on the auto-tester: anyone else getting the same 
 results?
All the builds on Travis are 64 bit, except for the one multilib configuration. As such, it's quite weird that you are seeing this failures. Which master commit in particular are you testing, and which LLVM version are you building against?
Looks like I was wrong about using merge-2.069, even though that branch was available in my local list, I used release-1.0.0 instead because I noticed it had much more recent commits. Here are the ldc commits used, all are stock with no local changes: master - 8bf013 release-1.0.0 - most likely 2d82da merge-2.070 - 6b000f I'm using dmd 2.070.0 to build the ddmd frontend and clang/clang++ to build the ldc glue layer.
Feb 25 2016
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 25 February 2016 at 19:41:50 UTC, Joakim wrote:
 I'm using dmd 2.070.0 to build the ddmd frontend and 
 clang/clang++ to build the ldc glue layer.
Oh, the local clang and llvm libraries are all 3.7.1.
Feb 25 2016