[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