This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] gen_lowpart and lvalues
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 24 Feb 2005 23:53:04 +0100
- Subject: Re: [PATCH] gen_lowpart and lvalues
- References: <Pine.LNX.email@example.com>
> 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.