Re: [PATCH] Fix PR middle-end/17793

[Jason Merrill <jason at redhat dot com>]

On Thu, 21 Oct 2004 09:20:27 +0200, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

>> The problem is that we end up with an ADDR_EXPR of a NOP_EXPR, which is
>> nonsensical; you can't take the address of a value.
>
> Note that the front-end doesn't build ADDR_EXPR <NOP_EXPR>, but instead
> ADDR_EXPR <VIEW_CONVERT_EXPR <NOP_EXPR>>.  The expander of VIEW_CONVERT_EXPR 
> knows how to make a temporary if needed.  Perhaps the problem is simply that 
> gimplify_addr_expr should not be trying to fiddle with VIEW_CONVERT_EXPR.

I think we do want gimplify_addr_expr to turn ADDR_EXPR <VIEW_CONVERT_EXPR>
into NOP_EXPR <ADDR_EXPR>.  So after that transformation we have

NOP_EXPR <pointer_type <record_type>>
 ADDR_EXPR <pointer_type <integer_type1>>
  NOP_EXPR <integer_type1>
   ARRAY_REF <integer_type2>

and we call gimplify_addr_expr again to continue reducing the ADDR_EXPR.
The code

      /* We use fb_either here because the C frontend sometimes takes
         the address of a call that returns a struct; see
         gcc.dg/c99-array-lval-1.c.  The gimplifier will correctly make
         the implied temporary explicit.  */
      ret = gimplify_expr (&TREE_OPERAND (expr, 0), pre_p, post_p,
                           is_gimple_addressable, fb_either);

ought then to allocate a temporary for the NOP_EXPR, so that we get

NOP_EXPR <pointer_type <record_type>>
 ADDR_EXPR <pointer_type <integer_type1>>
  VAR_DECL <integer_type1>

But we don't, because handled_component_p incorrectly accepts NOP_EXPR (and
CONVERT_EXPR, and NON_LVALUE_EXPR).  I think that's the bug.

Jason