Motivation
----------

1) It's required for Walter's work on using -betterC for the backend conversion:

https://github.com/dlang/dmd/pull/6907

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595

So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it.

Anyone objecting?

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
> Motivation
> ----------
>
> 1) It's required for Walter's work on using -betterC for the backend conversion:
>
> https://github.com/dlang/dmd/pull/6907
>
> 2) We start to run into random failures lately, e.g.
>
> https://github.com/braddr/d-tester/issues/63
> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048
>
> 3) There's also WIP to move dmd-cxx to 2.076.1:
>
> https://github.com/dlang/dmd/pull/7595
>
> So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it.
>
> Anyone objecting?

Yes! we cannot keep bumping the version of the compiler, personally I find 2.072 rather steep!
really we should be able to build with 2.068.

On Friday, 12 January 2018 at 16:21:25 UTC, Stefan Koch wrote:
> On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
>> Motivation
>> ----------
>>
>> 1) It's required for Walter's work on using -betterC for the backend conversion:
>>
>> https://github.com/dlang/dmd/pull/6907
>>
>> 2) We start to run into random failures lately, e.g.
>>
>> https://github.com/braddr/d-tester/issues/63
>> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048
>>
>> 3) There's also WIP to move dmd-cxx to 2.076.1:
>>
>> https://github.com/dlang/dmd/pull/7595
>>
>> So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it.
>>
>> Anyone objecting?
>
> Yes! we cannot keep bumping the version of the compiler, personally I find 2.072 rather steep!
> really we should be able to build with 2.068.

FYI: There has never been an official bump to 2.072
You can still build dmd with 2.068 - that's the version auto-tester uses.

However, I think you didn't understand my question.
We _will_ bump the minimal required version to compile DMD soon (see [1]).
That being said, what's the point in wasting hours of hours working around the bugs in 2.068.2 when we will do the bump one month later anyways?

[1] https://github.com/dlang/dmd/pull/6907

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
> Motivation
> ----------
>
> 1) It's required for Walter's work on using -betterC for the backend conversion:
>
> https://github.com/dlang/dmd/pull/6907

Not really, he just wants to dogfood betterC on the dmd backend when it's ported to D.

> 2) We start to run into random failures lately, e.g.
>
> https://github.com/braddr/d-tester/issues/63
> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

Seem like issues with 32-bit OS X instead.

> 3) There's also WIP to move dmd-cxx to 2.076.1:
>
> https://github.com/dlang/dmd/pull/7595

No idea when that will be ready.

> So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it.
>
> Anyone objecting?

This is going to require changes to ldc/gdc CI, as they actually maintain and test against that last C++ version of the common D frontend.  It will also affect ports to new platforms, as it presents another hoop to jump through.

I see little reason to jump now.  If it's done, it needs to be clearly documented.

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:
> On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
>> Motivation
>> ----------
>>
>> 1) It's required for Walter's work on using -betterC for the backend conversion:
>>
>> https://github.com/dlang/dmd/pull/6907
>
> Not really, he just wants to dogfood betterC on the dmd backend when it's ported to D.

Yeah and that requires:

-mv switch
- removal of the generated assert helper functions

Both are features which aren't present in 2.068
The entire reason why the PR wasn't merged yet is because the auto-tester hasn't been updated (and no one hacked these features into the gdc Perl wrapper).

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:
> On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
>> 2) We start to run into random failures lately, e.g.
>>
>> https://github.com/braddr/d-tester/issues/63
>> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048
>
> Seem like issues with 32-bit OS X instead.
>

It's actually a bug in dmd 2.068.2.  I was able to reproduce the segfault on my macbook.  If I went to the next version of dmd, namely, 2.069.0 then the issue went away.  I was also able to get a stack trace:
---
Obj::term(char const*) + 2285
obj_end(Library*, File*) + 37
tryMain(unsigned long, char const**) + 12066
_start + 203
start + 33
---

The `+ <num> ` is referring to the code offset in bytes from the beginning of the function, so the actual line of code where the invalid access occurs is somewhere inside Obj::term.  Unfortunately, that function is quite large (over 700 lines).

If we want to continue supporting dmd 2.068.2, I would recommend patching this bug.  I don't know how long we have been using this specific version of dmd 2.068.2 on the autotester, does anyone know?

On Friday, 12 January 2018 at 17:17:02 UTC, Seb wrote:
> On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:
>> On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
>>> Motivation
>>> ----------
>>>
>>> 1) It's required for Walter's work on using -betterC for the backend conversion:
>>>
>>> https://github.com/dlang/dmd/pull/6907
>>
>> Not really, he just wants to dogfood betterC on the dmd backend when it's ported to D.
>
> Yeah and that requires:
>
> -mv switch
> - removal of the generated assert helper functions
>
> Both are features which aren't present in 2.068
> The entire reason why the PR wasn't merged yet is because the auto-tester hasn't been updated (and no one hacked these features into the gdc Perl wrapper).

Let me rephrase what I wrote, as you did mention originally that bumping the compiler version was only required for betterC.  Walter wants to translate the dmd backend to D, but it doesn't have to be betterC, as others in that PR thread point out.

On Friday, 12 January 2018 at 17:17:25 UTC, Jonathan Marler wrote:
> On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:
>> On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
>>> 2) We start to run into random failures lately, e.g.
>>>
>>> https://github.com/braddr/d-tester/issues/63
>>> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048
>>
>> Seem like issues with 32-bit OS X instead.
>>
>
> It's actually a bug in dmd 2.068.2.  I was able to reproduce the segfault on my macbook.

Meaning what, it's reproducible with the 64-bit OS X tests also?

> If I went to the next version of dmd, namely, 2.069.0 then the issue went away.  I was also able to get a stack trace:
> ---
> Obj::term(char const*) + 2285
> obj_end(Library*, File*) + 37
> tryMain(unsigned long, char const**) + 12066
> _start + 203
> start + 33
> ---
>
> The `+ <num> ` is referring to the code offset in bytes from the beginning of the function, so the actual line of code where the invalid access occurs is somewhere inside Obj::term.  Unfortunately, that function is quite large (over 700 lines).
>
> If we want to continue supporting dmd 2.068.2, I would recommend patching this bug.  I don't know how long we have been using this specific version of dmd 2.068.2 on the autotester, does anyone know?

For now, I think you have no choice but to simply work around whatever that bug is.  We should drop support for 32-bit OS X sometime soon, and if that fixes the issue, you have no problem.

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:
> Motivation
> ----------
>
> 1) It's required for Walter's work on using -betterC for the backend conversion:
>
> https://github.com/dlang/dmd/pull/6907
>
> 2) We start to run into random failures lately, e.g.
>
> https://github.com/braddr/d-tester/issues/63
> https://github.com/dlang/dmd/pull/7569#issuecomment-356992048
>
> 3) There's also WIP to move dmd-cxx to 2.076.1:
>
> https://github.com/dlang/dmd/pull/7595
>
> So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it.
>
> Anyone objecting?

TLDR; I hope dmd needs a properly maintained bootstrap compiler branch with release tags of new versions every now and then as ldc does.

For packaging dmd on NixOS it is important to have a bootstrap compiler because the entire package tree of the distribution is build from scratch and no custom binaries can be used. (Well you can patch binaries with patchelf but that's not very nice and should probably only used for binary blobs)

Currently dmd 2.067.1 is used on NixOS as a bootstrap compiler and the last time I tried dmd-cxx it didn't work because of some build problems.
dmd 2.067.1 doesn't build with gcc6 which is the default for NixOS. This is not much of a problem because it can be easily overwritten to use gcc5 for the bootstrap compiler but still.
I also needed to patch things for the newest dmd version which I am slowly trying to upstream but since there are no bootstrap backports I can't get rid of those patches in the bootstrap package.

Which frontend version such a bootstrap branch has doesn't matter for me as long as it is maintained and I can build the newest version of dmd and all unit tests run successfully.

On 2018-01-12 19:45, Joakim wrote:

> For now, I think you have no choice but to simply work around whatever that bug is.  We should drop support for 32-bit OS X sometime soon, and if that fixes the issue, you have no problem.

Exactly. Apple will drop support for running 32bit applications in their next major OS release, 10.14.

-- 
/Jacob Carlborg

Typically support isn't dropped the instant the most recent version of the OS drops support but rather when the last supported OS release is no longer supported.  So, once 10.13 is no longer supported, then we can have the conversation about dropping 32 bit binary creation support.


On 1/13/2018 2:14 AM, Jacob Carlborg via Digitalmars-d wrote:
> On 2018-01-12 19:45, Joakim wrote:
>
>> For now, I think you have no choice but to simply work around whatever that bug is.  We should drop support for 32-bit OS X sometime soon, and if that fixes the issue, you have no problem.
>
> Exactly. Apple will drop support for running 32bit applications in their next major OS release, 10.14.
>