[dmd-internals] non-PODs again

[Johannes Pfau]

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

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