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
> 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.
Yes, that's indeed what happens.
> 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.
Maybe a bug (related to PR middle-end/17746), but not the bug we're discussing
here: handled_component_p is not invoked between the gimplification of
ADDR_EXPR <VIEW_CONVERT_EXPR> and the subsequent call to gimplify_addr_expr.
The problem is that the NOP_EXPR is stripped beforehand in the main loop of
the gimplifier because of
/* Strip away as many useless type conversions as possible
at the toplevel. */
STRIP_USELESS_TYPE_CONVERSION (*expr_p);
and in tree_ssa_useless_type_conversion_1:
/* If both the inner and outer types are integral types, then the
conversion is not necessary if they have the same mode and
signedness and precision, and both or neither are boolean. Some
code assumes an invariant that boolean types stay boolean and do
not become 1-bit bit-field types. Note that types with precision
not using all bits of the mode (such as bit-field types in C)
mean that testing of precision is necessary. */
else if (INTEGRAL_TYPE_P (inner_type)
&& INTEGRAL_TYPE_P (outer_type)
&& TYPE_MODE (inner_type) == TYPE_MODE (outer_type)
&& TYPE_UNSIGNED (inner_type) == TYPE_UNSIGNED (outer_type)
&& TYPE_PRECISION (inner_type) == TYPE_PRECISION (outer_type))
{
bool first_boolean = (TREE_CODE (inner_type) == BOOLEAN_TYPE);
bool second_boolean = (TREE_CODE (outer_type) == BOOLEAN_TYPE);
if (first_boolean == second_boolean)
return true;
}
so the code you quoted never sees the NOP_EXPR.
Jeff proposed to bypass this particular kind of NOP_EXPRs (I've now realized
my original patch was not specific enough) in gimplify_addr_expr. This could
be written as:
Index: gimplify.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.83
diff -u -p -r2.83 gimplify.c
--- gimplify.c 11 Oct 2004 12:57:09 -0000 2.83
+++ gimplify.c 22 Oct 2004 06:52:56 -0000
@@ -3093,6 +3093,13 @@ gimplify_addr_expr (tree *expr_p, tree *
??? The interactions of VIEW_CONVERT_EXPR and aliasing is not at
all clear. The impact of this transformation is even less clear. */
+
+ /* If the operand is a useless conversion, look through it. Doing so
+ guarantees that the ADDR_EXPR and its operand will remain of the
+ same type. */
+ if (tree_ssa_useless_type_conversion (TREE_OPERAND (op0, 0)))
+ op0 = TREE_OPERAND (op0, 0);
+
*expr_p = fold_convert (TREE_TYPE (expr),
build_fold_addr_expr (TREE_OPERAND (op0, 0)));
ret = GS_OK;
Do you agree with this approach? I think it won't preclude us from making a
temporary for non-useless NOP_EXPRs if we deem it necessary.
--
Eric Botcazou