Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> OK, now I understand.  Unfortunately, *not* "accepting" it is also
> problematic since the gimplifier, if it doesn't accept that, will make a
> temporary for the result of the VIEW_CONVERT_EXPR, so the ADDR_EXPR would
> be returning the address of that temporary and not the operand of the
> V_C_E, which is exactly what you *don't* want to happen for TYPE_ALIGN_OK.

That's my understanding too.  handled_component_p should accept this kind of 
VIEW_CONVERT_EXPRs, otherwise we would need to add (|| ....) clauses to every 
single test mentioning handled_component_p at the tree level.  I think the 
TYPE_ALIGN_OK thing should stay at the RTL level.

> So this maybe indeed be the single exception to the correspondance between
> get_inner_refrence and handled_component_p.  I don't particularly care
> for that, but if there's no other way, we should at least document it
> *very* clearly ...

Agreed, I'm going to try and hopefully this will be sufficient to convince the 
other Richard. :-)


About stepping up the alignment in expand_expr_addr_expr_1: after thinking a 
little more, I'm now wondering if this is really necessary.  It was necessary 
to do so with the 3.4 code for every VIEW_CONVERT_EXPR because ADDR_EXPR 
trees were going through:

expand_expr:
    case ADDR_EXPR:
          [...]
	  /* If OP0 is not aligned as least as much as the type requires, we
	     need to make a temporary, copy OP0 to it, and take the address of
	     the temporary.  We want to use the alignment of the type, not of
	     the operand.  Note that this is incorrect for FUNCTION_TYPE, but
	     the test for BLKmode means that can't happen.  The test for
	     BLKmode is because we never make mis-aligned MEMs with
	     non-BLKmode.

	     We don't need to do this at all if the machine doesn't have
	     strict alignment.  */
	  if (STRICT_ALIGNMENT && GET_MODE (op0) == BLKmode
	      && (TYPE_ALIGN (TREE_TYPE (TREE_OPERAND (exp, 0)))
		  > MEM_ALIGN (op0))
	      && MEM_ALIGN (op0) < BIGGEST_ALIGNMENT)
	    {
	      tree inner_type = TREE_TYPE (TREE_OPERAND (exp, 0));
	      rtx new;

	      if (TYPE_ALIGN_OK (inner_type))
		abort ();

	      if (TREE_ADDRESSABLE (inner_type))
		{
		  /* We can't make a bitwise copy of this object, so fail.  */
		  error ("cannot take the address of an unaligned member");
		  return const0_rtx;
		}

	      new = assign_stack_temp_for_type
		(TYPE_MODE (inner_type),
		 MEM_SIZE (op0) ? INTVAL (MEM_SIZE (op0))
		 : int_size_in_bytes (inner_type),
		 1, build_qualified_type (inner_type,
					  (TYPE_QUALS (inner_type)
					   | TYPE_QUAL_CONST)));


With the 4.0 code, the ADDR_EXPR expander has been rewritten into:

    case ADDR_EXPR:
      return expand_expr_addr_expr (exp, target, tmode, modifier);

and neither expand_expr_addr_expr nor expand_expr_addr_expr_1 make 
temporaries, based on alignment conditions or not.  So my understanding is 
that the temporaries business for ADDR_EXPRs has been hoisted ouf of the 
expander and integrated in the gimplifier.

I think that, when expand_expr_addr_expr is invoked on an ADDR_EXPR tree, it 
will make no difference whether the alignment gets explicitly stepped up when 
a VIEW_CONVERT_EXPR is encountered or not, because the final object the 
address of which will be returned will be the same.

What do you think?

-- 
Eric Botcazou