[dmd-internals] What does POD imply for backends

Walter Bright walter at digitalmars.com
Sat Feb 16 12:06:03 PST 2013


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?
>



More information about the dmd-internals mailing list