[dmd-internals] What does POD imply for backends
Walter Bright
walter at digitalmars.com
Sat Feb 16 12:24:41 PST 2013
Also, non-POD cannot be bit-copied, meaning it cannot be copied in and out of
registers.
On 2/16/2013 12:06 PM, Walter Bright wrote:
> A non-POD cannot be in registers because its address gets taken for
> constructors/destructors.
>
> On 2/16/2013 11:36 AM, Johannes Pfau wrote:
>> While tracking down a bug in gdc I realized that gdc does nothing special for
>> POD/non-POD types yet. That at least caused one bug where the runtime va_arg
>> code expected a non-POD parameter to be passed on the stack but gcc passes it
>> in registers.
>>
>> So to implement (non-)POD types correctly in GDC it would be good to know:
>>
>> * Non-POD types can't be passed in registers for va_arg code. What's the
>> reason for this?
>> * Can Non-PODs be passed in registers to regular, non-variadic functions?
>> * Can Non-PODs be returned from functions in registers?
>> * The spec says the backend may create bit copies as convenient. Is this true
>> for Non-PODs as well?
>> * In GCC a non-POD type must always have an address (i.e it can never be in
>> registers). Is this true for D as well?
>>
>> Is there anything more the backend must handle in regard to POD/non-POD types?
>>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
More information about the dmd-internals
mailing list