To POD or not to POD

[Iain Buclaw]

On Feb 13, 2013 6:55 PM, "Johannes Pfau" <nospam at example.com> wrote:
>
> Am Wed, 13 Feb 2013 17:17:06 +0000
> schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
>
> > On 13 February 2013 15:20, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
> >
> > >>
> > >> Complete test case:
> > >> https://gist.github.com/jpf91/4944999
> > >>
> > >> -----
> > >>
> > >>
../../objdir-4.7/x86_64-unknown-linux-gnu/libphobos/dm-test.reduced/datetime2.d:22:
> > >> internal compiler error: in create_tmp_var, at gimplify.c:479
> > >> 0x804509 -----
> > >>
> > >>
> > >
> > > Ahh, that's because of this piece of codegen:
> > >
> > > SAVE_EXPR <*test.Date.this (&((void) (__ctmp971 =
> > > _D4test4Date6__initZ);, __ctmp971), 0)>
> > >
> > >
> > > Gimple doesn't like the dereference in SAVE_EXPR.  This should work.
> > >
> > > tree
> > > IRState::makeTemp (tree t)
> > > {
> > >   tree type = TREE_TYPE (t);
> > >   if (TREE_CODE (type) != ARRAY_TYPE && !TREE_ADDRESSABLE (type))
> > >     return save_expr (t);
> > >
> > >   return stabilize_reference (t);
> > > }
> > >
> > >
> > > So the generated code is now:
> > >
> > > *SAVE_EXPR <test.Date.this (&((void) (__ctmp971 =
> > > _D4test4Date6__initZ);, __ctmp971), 0)>
> > >
> > >
> > After some more playing about, David's suggestion would be the
> > quickest. ;-)
> >
>
> Indeed. But what if the example is slightly adjusted to define a
> destructor or postblit instead of the constructor? Does the backend
> know about those or would it still try to pass Date in registers?
>

Backend doesn't know of those, and yes it would pass it in registers
because it will always see structs as a value type rather than a reference
(though passing round 'this' should always be done in memory).

Regards
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130213/897f9ecf/attachment.html>