On 26 January 2016 at 16:33, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 26/01/2016 5:29 PM, Manu via Digitalmars-d wrote:
>>
>>
>> I tried to build DMD myself, doesn't build with vs2015: https://issues.dlang.org/show_bug.cgi?id=15611
>>
>> *sigh* .. everything's always so hard! It's exhausting.
>>
>
> Get with the times, vs2015 is so last year.

Why doesn't the CI matrix build with all common compilers?

On 26 January 2016 at 15:20, Manu <turkeyman@gmail.com> wrote:
> On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>>
>>> On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> I brought a work laptop home this weekend in anticipation ;)
>>>>
>>>>
>>>>
>>>> Here ya go:
>>>>
>>>>    https://github.com/D-Programming-Language/dmd/pull/5364
>>>>
>>>> Be wary of:
>>>>
>>>>    https://issues.dlang.org/show_bug.cgi?id=15589
>>>>
>>>> and use the workaround as necessary. This is lower priority, so I won't
>>>> be
>>>> dealing with it for a bit.
>>>
>>>
>>> Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610
>>>
>>> C++ methods with multiple-inheritence expect that 'this' is a pointer
>>> to the base class that introduced the function.
>>> When using C++ 'interface's, which C++ just treats like normal
>>> multiple-inheritence, C++ expects that the 'this' pointer is adjusted
>>> to the offset of the interface's vtable.
>>>
>>> If I have:
>>> extern(C++) interface Interface { voif f(); }
>>> extern(C++) class C : Base, Interface
>>> {
>>>    void f();
>>> }
>>>
>>> Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this' is a pointer to 'Interface', and then it crashes accessing members at incorrect offsets.
>>>
>>
>> The PR 5364 does this. (And only Microsoft Win64 has this effect.)
>
> Oh okay. I thought that PR was about correctly locating the vtable and function offsets. I'll wait till that's merged.

Okay, tried today's nightly [1]; built 27-Jan-2016 05:22

On 26 January 2016 at 15:20, Manu <turkeyman@gmail.com> wrote:
> On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>>
>>> On 24 January 2016 at 20:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> I brought a work laptop home this weekend in anticipation ;)
>>>>
>>>>
>>>>
>>>> Here ya go:
>>>>
>>>>    https://github.com/D-Programming-Language/dmd/pull/5364
>>>>
>>>> Be wary of:
>>>>
>>>>    https://issues.dlang.org/show_bug.cgi?id=15589
>>>>
>>>> and use the workaround as necessary. This is lower priority, so I won't
>>>> be
>>>> dealing with it for a bit.
>>>
>>>
>>> Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610
>>>
>>> C++ methods with multiple-inheritence expect that 'this' is a pointer
>>> to the base class that introduced the function.
>>> When using C++ 'interface's, which C++ just treats like normal
>>> multiple-inheritence, C++ expects that the 'this' pointer is adjusted
>>> to the offset of the interface's vtable.
>>>
>>> If I have:
>>> extern(C++) interface Interface { voif f(); }
>>> extern(C++) class C : Base, Interface
>>> {
>>>    void f();
>>> }
>>>
>>> Calling c.f(), D is passing 'this' unaltered, but C++ expects 'this' is a pointer to 'Interface', and then it crashes accessing members at incorrect offsets.
>>>
>>
>> The PR 5364 does this. (And only Microsoft Win64 has this effect.)
>
> Oh okay. I thought that PR was about correctly locating the vtable and function offsets. I'll wait till that's merged.

Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
("committed 21 hours ago", which was during the 26th)
Still crashes. Setup looks similar; leading to the call, RAX is the
vtable and RCX is 'this', there is a moment prior to the call where
they are both correct for the call, and then there are few extra
opcodes which dereferences each of them until they are rubbish values,
then tries to make the call, which jumps to a bad address.

Bit of this: https://img42.com/oqN6y ;)

I am off work for 3 weeks from Friday, I don't think I have any more time for this sadly.

On 1/27/2016 2:50 AM, Manu via Digitalmars-d wrote:
> On 26 January 2016 at 15:20, Manu <turkeyman@gmail.com> wrote:
>> On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>>> Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610
> Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
> Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
> ("committed 21 hours ago", which was during the 26th)
> Still crashes. Setup looks similar; leading to the call, RAX is the
> vtable and RCX is 'this', there is a moment prior to the call where
> they are both correct for the call, and then there are few extra
> opcodes which dereferences each of them until they are rubbish values,
> then tries to make the call, which jumps to a bad address.
>
> Bit of this: https://img42.com/oqN6y ;)

I can't do anything with this, as the code submitted in the bug report is incomplete.

> I am off work for 3 weeks from Friday, I don't think I have any more
> time for this sadly.

Have a nice vacation, look forward to you getting back!

On 1/27/2016 3:56 PM, Walter Bright wrote:
> I can't do anything with this, as the code submitted in the bug report is
> incomplete.

I think the problem is the 'final'. Try removing it as a workaround.

On 28 January 2016 at 09:56, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/27/2016 2:50 AM, Manu via Digitalmars-d wrote:
>>
>> On 26 January 2016 at 15:20, Manu <turkeyman@gmail.com> wrote:
>>>
>>> On 26 January 2016 at 15:11, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 1/25/2016 9:02 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>> Next blocker: https://issues.dlang.org/show_bug.cgi?id=15610
>>
>> Tried today's nightly (https://builds.dawg.eu/dmd-nightly/)
>> Built 27-Jan-2016 05:22, which is definitely after 5364 was merged
>> ("committed 21 hours ago", which was during the 26th)
>> Still crashes. Setup looks similar; leading to the call, RAX is the
>> vtable and RCX is 'this', there is a moment prior to the call where
>> they are both correct for the call, and then there are few extra
>> opcodes which dereferences each of them until they are rubbish values,
>> then tries to make the call, which jumps to a bad address.
>>
>> Bit of this: https://img42.com/oqN6y ;)
>
>
> I can't do anything with this, as the code submitted in the bug report is incomplete.

I hoped the winkey face would imply that this was a joke...
Although the joke's on me; the point is, it takes me a really long
time to trace through and try and understand what's going on. Finding
my way to this image is not a short process. It was 2am before trying
to reduce what I found... didn't get to it last night >_<

On 28 January 2016 at 10:27, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/27/2016 3:56 PM, Walter Bright wrote:
>>
>> I can't do anything with this, as the code submitted in the bug report is incomplete.
>
>
> I think the problem is the 'final'. Try removing it as a workaround.

Okay, I can try that quickly tonight.
99% of functions are final, and about 80% of virtual functions are final too.

On 1/27/2016 4:45 PM, Manu via Digitalmars-d wrote:
>> I think the problem is the 'final'. Try removing it as a workaround.
> Okay, I can try that quickly tonight.
> 99% of functions are final, and about 80% of virtual functions are final too.

I understand, and I'll see if I can figure out a proper fix. Thanks for your patience with this!

On 1/27/2016 4:43 PM, Manu via Digitalmars-d wrote:
> I hoped the winkey face would imply that this was a joke...
> Although the joke's on me; the point is, it takes me a really long
> time to trace through and try and understand what's going on. Finding
> my way to this image is not a short process. It was 2am before trying
> to reduce what I found... didn't get to it last night >_<

I understand and appreciate your efforts. And another upside of small examples is they go into the test suite so they *stay* fixed! Nobody likes regressions.