Bump the minimal version required to compile DMD to 2.076.1

[Joakim]

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.