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

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?

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

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.

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.

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