[PATCH] gen_lowpart and lvalues

[Eric Botcazou]

> Have you considered something as simple as, in the VIEW_CONVERT_EXPR
> case in expr.c's expand_expr_real moving the gen_lowpart call a few
> lines further down inside the GET_CODE (op0) != MEM?  Given that the
> semantics of Ada's VIEW_CONVERT_EXPR are so unique that they can't
> be represented by any of GCC's other tree-codes, it hardly seems
> surprising that they might perhaps need to take a little more care in
> expanding RTL than blindly calling GCC's NOP_EXPR/CONVERT_EXPR
> infrastructure directly.  Perhaps a VIEW_CONVERT_EXPR of a MEM
> operand merits a few lines of custom code of its own?

I think we need a variant of gen_lowpart that preserves lvalues again, 
whatever name it is ultimately given.

> Another approach might be to call gen_lowpart_common directly instead of
> the higher-level gen_lowpart and then check for a NULL_RTX return value.
> Then, if that fails, call adjust_address with the appropriate offset.
> Infact, you're already calling adjut_address in the VIEW_CONVERT_EXPR
> code, just not handling the padding issues of integer fields, instead
> mis-using gen_lowpart to handle that for you.

I'd rather have a single function that handles most (all) of the cases.

> A reasonable alternative?  I'd help test it myself but Ada patches
> take months to get reviewed and you didn't include any testcases
> or examples in your post to motivate/test this change :)

Sorry, the testcase is somewhat pathological (although legal Ada code) and I'm 
still wondering whether gigi does the right thing in the first place.

I think we need to agree on a clear semantics; we'll adjust gigi from that.

Thanks for your feedback.

--
Eric Botcazou