Am 08.03.2013 05:52, schrieb Maxim Fomin:


2013/3/8 Walter Bright <[email protected] <mailto:[email protected]>>


    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-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Reply via email to