In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.

However, on my local box (Linux 32-bit), the test passes...

I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.? So that's the only thing I can think of.? I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.? Is this still true?

Sorry about the break, I hope I can figure out why soon.


-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110621/d5c7d033/attachment.html>

On 6/21/2011 5:55 AM, Steve Schveighoffer wrote:
> In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.
> 
> However, on my local box (Linux 32-bit), the test passes...
> 
> I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.  So that's the only thing I can think of.  I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.  Is this still true?
> 
> Sorry about the break, I hope I can figure out why soon.
> 
> -Steve

The auto-tester always tests with the most recent submit of all three parts.  That's how releases are done so that's what needs to be tested.  For the most part, attempts are made to minimize the cross-package damage as changes are made, which helps minimize the number of times that upper layer developers HAVE to test with tip of everything, but that's not always the case.

Regarding the 32/64 bit issues, you can over the cursor over each of the builds to get more details about it.  To short circuit that, the first number is how dmd is built (as a 32 or 64 bit application) and the second number is the output of dmd (32 bit or 64 bit code generation).

The windows test for both druntime and phobos is different than the posix platforms.  It does a big binary build rather than one binary per .d file.  I wish it was more like the posix test pattern, but no one has invested the time to change the win32 makefiles.

On 2011-06-21 05:55, Steve Schveighoffer wrote:
> In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.
> 
> However, on my local box (Linux 32-bit), the test passes...
> 
> I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.  So that's the only thing I can think of.  I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.  Is this still true?
> 
> Sorry about the break, I hope I can figure out why soon.

I'm not sure that we have an official policy on whether you should be using the latest HEAD of dmd or the last release, but the autotester _does_ use the latest git HEAD of dmd, and I believe that there _have_ been cases where the latest HEAD was required. Personally, I always use the latest HEAD.

- Jonathan M Davis

>________________________________
>From: Brad Roberts <braddr at puremagic.com>
>To: d-runtime at puremagic.com
>Sent: Tuesday, June 21, 2011 11:29 AM
>Subject: Re: [D-runtime] auto-tester failing, local test passing
>
>On 6/21/2011 5:55 AM, Steve Schveighoffer wrote:
>> In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.
>> 
>> However, on my local box (Linux 32-bit), the test passes...
>> 
>> I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.? So that's the only thing I can think of.? I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.? Is this still true?
>> 
>> Sorry about the break, I hope I can figure out why soon.
>> 
>> -Steve
>
>The auto-tester always tests with the most recent submit of all three parts.? That's how releases are done so that's what needs to be tested.? For the most part, attempts are made to minimize the cross-package damage as changes are made, which helps minimize the number of times that upper layer developers HAVE to test with tip of everything, but that's not always the case.

OK, it looks like in this case it might have nothing to do with using HEAD, since I noticed after sending this message that the 32-bit tests are passing.? It looks more like a 64-bit problem, and I'm not sure if it's something I'm doing or not, I don't have a 64-bit box to test with.? I would suspect it might have something to do with the way I'm checking to see if the TypeInfo has overridden postblit.


I'll continue to test with the latest released dmd, unless it starts failing unit tests against the HEAD phobos/druntime.? I think that's probably the more reliable option.


>Regarding the 32/64 bit issues, you can over the cursor over each of the builds to get more details about it.? To short circuit that, the first number is how dmd is built (as a 32 or 64 bit application) and the second number is the output of dmd (32 bit or 64 bit code generation).

Thanks, I found this out seconds after sending this message :)? BTW the tester looks very spiffy!? I like the rounded edges, and the little color coded history on the right of the boxes.

>The windows test for both druntime and phobos is different than the posix platforms.? It does a big binary build rather than one binary per .d file.? I wish it was more like the posix test pattern, but no one has invested the time to change the win32 makefiles.

My concern is mostly this message in the passing output:

Warning 2: File Not Found druntime.lib

-Steve

On 2011-06-21 08:29, Brad Roberts wrote:
> On 6/21/2011 5:55 AM, Steve Schveighoffer wrote:
> > In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.
> > 
> > However, on my local box (Linux 32-bit), the test passes...
> > 
> > I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.  So that's the only thing I can think of.  I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.  Is this still true?
> > 
> > Sorry about the break, I hope I can figure out why soon.
> > 
> > -Steve
> 
> The auto-tester always tests with the most recent submit of all three parts.  That's how releases are done so that's what needs to be tested. For the most part, attempts are made to minimize the cross-package damage as changes are made, which helps minimize the number of times that upper layer developers HAVE to test with tip of everything, but that's not always the case.
> 
> Regarding the 32/64 bit issues, you can over the cursor over each of the builds to get more details about it.  To short circuit that, the first number is how dmd is built (as a 32 or 64 bit application) and the second number is the output of dmd (32 bit or 64 bit code generation).
> 
> The windows test for both druntime and phobos is different than the posix
> platforms.  It does a big binary build rather than one binary per .d file.
>  I wish it was more like the posix test pattern, but no one has invested
> the time to change the win32 makefiles.

It would be more consistent to have the Windows tests done the same as the Posix tests, and it would cause fewer issues with the compiler running out of memory, but it _has_ shown actual bugs upon occasion (such as circular imports), so I'm a bit divided on the matter, personally. On the whole, I agree with you and think that it should be like on Posix, but the difference has proven useful from time to time.

- Jonathan M Davis

On 6/21/2011 8:55 AM, Steve Schveighoffer wrote:
> 
>> On 6/21/2011 5:55 AM, Steve Schveighoffer wrote:
>>> In the latest commit I just pulled (druntime pull request 29), the auto tester is now failing one of the unit tests.
>>>
>>> However, on my local box (Linux 32-bit), the test passes...
>>>
>>> I'm testing with dmd 2.053, and I think the auto-tester tests with the dmd out of github.  So that's the only thing I can think of.  I was told that phobos/druntime developers should not be using the HEAD dmd, they should be using the last released one.  Is this still true?
>>>
>>> Sorry about the break, I hope I can figure out why soon.
>>>
>>> -Steve
>>
>> The auto-tester always tests with the most recent submit of all three parts.  That's how releases are done so that's what needs to be tested.  For the most part, attempts are made to minimize the cross-package damage as changes are made, which helps minimize the number of times that upper layer developers HAVE to test with tip of everything, but that's not always the case.
> 
> OK, it looks like in this case it might have nothing to do with using HEAD, since I noticed after sending this message that the 32-bit tests are passing.  It looks more like a 64-bit problem, and I'm not sure if it's something I'm doing or not, I don't have a 64-bit box to test with.  I would suspect it might have something to do with the way I'm checking to see if the TypeInfo has overridden postblit.
> 
> 
> I'll continue to test with the latest released dmd, unless it starts failing unit tests against the HEAD phobos/druntime.  I think that's probably the more reliable option.
> 

There's an important difference between 32 and 64 that matters here.  The druntime call chains:

on 32:

_d_arrayappendcT
  _d_arrayappendT
    _d_arrayappendcTX
      __doPostblit
    __doPostblit

on 64:

_d_arrayappendcTX
  __doPostblit

The problem is that part of the logic for array appending was moved from the runtime to the compiler's codegen process for 64 bits.  So the compiler needs to be taught to run the postblit after calling _d_arrayappendcTX or that work moved back to the runtime.  The reasons to switch from _d_arrayappendcT to the TX version were to avoid the complexities of vararg calling.

That code is in e2ir.c, search for RTLSYM_ARRAYAPPENDCTX.

----- Original Message -----
> From: Brad Roberts <braddr at puremagic.com>
> There's an important difference between 32 and 64 that matters here.? The
> druntime call chains:
> 
> on 32:
> 
> _d_arrayappendcT
> ? _d_arrayappendT
> ? ? _d_arrayappendcTX
> ? ? ? __doPostblit
> ? ? __doPostblit
> 
> on 64:
> 
> _d_arrayappendcTX
> ? __doPostblit

__doPostblit is not a compiler-called function, it's something I added to modularize the postblitting (it has some optimizations to not blindly try calling postblit on every element, even when it won't do anything).

The dT version first calls cTX to extend the array.? The __doPostblit call in cTX is because it needs to create a new block of data, and so it needs to move the data from the old block to the new block.? The __doPostblit call in dT is to do the postblit on the data being appended.

Now, the above might be plausibly valid if you are appending a temporary and the complier simply extends the array and constructs the new value inside the array, but that is not the case here.? I've looked at the code generation (can't run it, but I can disassemble it :) ) and it clearly is simply copying stack data to the array without doing a postblit.

So I agree this is a bug in the 64-bit compiler.

> The problem is that part of the logic for array appending was moved from the
> runtime to the compiler's codegen process
> for 64 bits.? So the compiler needs to be taught to run the postblit after
> calling _d_arrayappendcTX or that work moved
> back to the runtime.? The reasons to switch from _d_arrayappendcT to the TX
> version were to avoid the complexities of
> vararg calling.

I think it's fine to leave it the way it is, but the compiler has to call the postblit after copying.? The good news is, the check for whether the postblit exists can be done at compile time, whereas in my 32-bit code it must be done at runtime using the typeinfo.

Should I file a bug?? I'm very not comfortable changing the compiler myself, and especially when I can't test it...

We can also comment out that test for now as an interim fix.

-Steve

>________________________________
>From: Steve Schveighoffer <schveiguy at yahoo.com>
>Should I file a bug?? I'm very not comfortable changing the compiler myself, and especially when I can't test it...
>


filed, this should be fixed soon to allow 64-bit druntime to pass the autotester.

http://d.puremagic.com/issues/show_bug.cgi?id=6234

-Steve