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 


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 

 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 

 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