[dmd-internals] non-PODs again

[Johannes Pfau]

Am 08.03.2013 13:15, schrieb Maxim Fomin:
>
>
> 2013/3/8 Johannes Pfau <johannespfau at googlemail.com 
> <mailto:johannespfau at googlemail.com>>
>
>     Am 08.03.2013 05:52, schrieb Maxim Fomin:
>>
>>
>>     2013/3/8 Walter Bright <walter at digitalmars.com
>>     <mailto:walter at digitalmars.com>>
>>
>>
>>         On 3/7/2013 12:19 PM, Johannes Pfau wrote:
>>
>>             Am 07.03.2013 20:45, schrieb Walter Bright:
>>
>>
>>                 On 3/7/2013 9:36 AM, Johannes Pfau wrote:
>>
>>                     I'm sorry I have to pester you with this again,
>>                     but I still have some questions regarding POD
>>                     types and I'd like to fix this in GDC.
>>
>>                     So from last discussion:
>>                     >> Wouldn't it be legal to still pass non-PODs in
>>                     registers when calling functions and only copying
>>                     them back to
>>                     >> the stack if the address is needed? As we pass
>>                     structs by value anyway, how could this be
>>                     problematic?
>>                     >
>>                     > No, not allowed. Consider why there are copy
>>                     constructors, and what they do.
>>
>>                     I compiled some test programs with dmd and dmd
>>                     _does_ pass non-POD values in registers as I
>>                     suggested above.
>>                     See this example:
>>                     https://gist.github.com/jpf91/5064703 (D)
>>                     https://gist.github.com/jpf91/5064764 (ASM)
>>
>>
>>                 That's because objects with constructors are now
>>                 regarded as POD.
>>
>>
>>             This example uses a postblit to make sure the type is not
>>             a POD. It's obvious in the ASM that the copy ctor is called,
>>
>>
>>         Oops, I missed that. It's a bug in dmd.
>>
>>
>>     Isn't there another bug with struct parameter which is copied
>>     twice - on caller and callee side?
>>
>>     function  D main
>>     Date d = _D1e4Date6__initZ;
>>     setDate((Date __cpcttmp7 = __cpcttmp7.__cpctor(d); , __cpcttmp7))
>>
>>     function  e.setDate
>>     x.opAssign((Date __cpcttmp6 = __cpcttmp6.__cpctor(d); , __cpcttmp6))
>>
>     setDate assigns d to the global variable x so the second call to
>     the cpctor seems to be caused by that and valid.
>
>     -- 
>     Johannes Pfau
>
>
> DMD still generates double copy if variable is changed to local
>
> void setDate(Date d)
> {
> Date x;
> x = d;
> }
>
> function  e.setDate
> Date x = _D1e4Date6__initZ;
> x.opAssign((Date __cpcttmp6 = __cpcttmp6.__cpctor(d); , __cpcttmp6))
>
> function  D main
> Date d = _D1e4Date6__initZ;
> setDate((Date __cpcttmp7 = __cpcttmp7.__cpctor(d); , __cpcttmp7))
>
> Anyway whether variable is tls or not is irrelevant. Compiler should 
> not make a copy when assigning.
>
You're right I confused this with initialization which needs the call to 
the copy ctor, but a simple assignment should not call it.

-- 
Johannes Pfau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20130308/722e2152/attachment.html>