Array allocation on struct initialization

[Peter Alexander]

On 29/12/11 5:13 PM, Benjamin Thaut wrote:
> I'm currently trying to make a nongc safe version of the d-runtime and
> stumbeled on my favorite WTF moment so far:
>
> The following programm:
>
> struct MemoryBlockInfo
> {
> size_t size;
> long[10] backtrace;
> int backtraceSize;
>
> this(size_t size)
> {
> this.size = size;
> }
> }
>
> int main(string[] argv)
> {
> MemoryBlockInfo info;
> info = MemoryBlockInfo.init;
> }
>
> This produces the following disassembly:
> 0040385A mov dword ptr [info],eax
> 0040385D push 0Ah
> 0040385F mov ecx,offset TypeInfo_G10l at __init (41E260h)
> 00403864 push ecx
> 00403865 call rt at lifetime@_d_arrayliteralTX (404664h)
> 0040386A mov dword ptr [_TMP0],eax
> 0040386D mov dword ptr [eax],0
> 00403873 mov dword ptr [eax+4],0
> 0040387A mov dword ptr [eax+8],0
> 00403881 mov dword ptr [eax+0Ch],0
> 00403888 mov dword ptr [eax+10h],0
> 0040388F mov dword ptr [eax+14h],0
> 00403896 mov dword ptr [eax+18h],0
> 0040389D mov dword ptr [eax+1Ch],0
> 004038A4 mov dword ptr [eax+20h],0
> 004038AB mov dword ptr [eax+24h],0
> 004038B2 mov dword ptr [eax+28h],0
>
> Why in hell is there a call to rt.lieftime._d_arrayliteralTX ???
> I always thought that the init data is some global immutable data block
> that never changes thorughout the program execution, so why does it need
> to be copied? With behaviour like this it is pretty much impossible to
> make a nongc safe version of D at all.
>
> Is this a compiler bug or intended behaviour?

Seems like a bug (or at least a misfeature).

If you do this instead:

MemoryBlockInfo info;
MemoryBlockInfo infoInit;
info = infoInit;

Then you don't get the array literal memory allocation i.e. it only 
happens when assigning to T.init explicitly.