[D-runtime] auto-tester failing, local test passing
Steve Schveighoffer
schveiguy at yahoo.com
Wed Jun 22 05:46:27 PDT 2011
----- 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
More information about the D-runtime
mailing list