This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Your June 7 change to expand_expr
- To: mark at markmitchell dot com
- Subject: Re: Your June 7 change to expand_expr
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 30 Jun 1998 19:06:09 -0600
- cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, egcs-bugs at cygnus dot com, John Carr <jfc at mit dot edu>
- Reply-To: law at cygnus dot com
In message <199806302337.QAA26396@smtp.earthlink.net>you write:
>
> Recent GCC2 changes were just merged into EGCS. One C++ program I
> have (but which I cannot release) began generating incorrect output.
> I tracked the problem down to this change:
>
> Sun Jun 7 09:30:31 1998 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
>
> * expr.c (expand_expr, case INDIRECT_EXPR): A dereference of
> a REFERENCE_TYPE is always considered in a structure. Likewise for
> a dereference of a NOP_EXPR whose input is a pointer to aggregate.
>
> In particular, to the bit about a dereference of a REFERENCE_TYPE be
> always considered to be in a structure. I don't know exactly *why*
> this was causing the problem, although I'm guessing it's because EGCS
> does some alias analysis that looks at MEM_IN_STRUCT_P.
It seems wrong to assume that an dereference of a REFERENCE_TYPE is
always an aggregate reference. Can't we have a REFERENCE_TYPE that
refers to a non-aggregate?
Seems to me it should depend on the underlying type.
> if (...
> /* If the pointer is actually a REFERENCE_TYPE, this could
> be pointing into some aggregate too. */
> || TREE_CODE (TREE_TYPE (exp1)) == REFERENCE_TYPE
> ...)
> MEM_IN_STRUCT_P (temp) = 1;
>
> Why should all references be considered as possibly pointing into
> structures? If they should be, why shouldn't pointers?
Exactly.
> The next hunk:
>
> /* This may have been an array reference to the first element
> that was optimized away from being an addition. */
> || (TREE_CODE (exp1) == NOP_EXPR
> && ((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp1, 0)))
> == REFERENCE_TYPE)
> || ((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp1, 0)))
> == POINTER_TYPE)
> && (AGGREGATE_TYPE_P
> (TREE_TYPE (TREE_TYPE
> (TREE_OPERAND (exp1, 0))))))))
>
> also seems suspicious to me. Besides the reference issue, how do we
> know whether the NOP_EXPR was the degenerate addition case mentioned?
This is trying to deal with a real issue -- we need to detect this case
(not only in expr.c, but elsewhere).
> Jeff, for now I recommend the following patch to EGCS.
I think that's a little premature at this time.
jeff