This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/17793
- From: Jason Merrill <jason at redhat dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Oct 2004 19:03:13 -0400
- Subject: Re: [PATCH] Fix PR middle-end/17793
- References: <10410192256.AA14773@vlsi1.ultra.nyu.edu>
On Tue, 19 Oct 04 18:56:11 EDT, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:
> Hmm? It makes no sense to have a NOP_EXPR inside a VIEW_CONVERT_EXPR.
> A NOP_EXPR is an rvalue conversion; a VIEW_CONVERT_EXPR is an lvalue
> conversion, which cannot be applied to the rvalue produced by a
> NOP_EXPR.
>
> Sure it can. In normal usage, all of the conversions return values.
> VIEW_CONVERT_EXPR can be used as part of an LHS, while NOP_EXPR can't,
> but that's a minor distinction and that usage is sort of dubious anyway.
Minor? It seems pretty central to me. VIEW_CONVERT_EXPR operates on the
reference, NOP_EXPR on the value.
> This seems like a front end bug; the NOP_EXPR should be
> stripped when the VIEW_CONVERT_EXPR is added.
>
> I don't think that's necessarily correct: I can easily see cases where
> you'd want both. For example, you have an 8-bit integer and NOP_EXPR
> that converts it into 32-bit integer, then a VIEW_CONVERT_EXPR that
> converts it into an array of four 8-bit integers.
Hmm, OK. I would expect gimplification of that example to create a
temporary for the NOP_EXPR.
Jason