To POD or not to POD
Johannes Pfau
nospam at example.com
Wed Feb 13 10:52:10 PST 2013
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?
For this current test case the issue seems to be that DMD creates a
StructLiteralExp for the default constructor call which is of course not
an lvalue and gimple seems to dislike that. But I don't know how to fix
this and there could be many more cases...
More information about the D.gnu
mailing list