Semantics of MODIFY_EXPR with CONSTRUCTOR rhs

[Richard Henderson]

On Mon, Aug 02, 2004 at 06:58:26PM -0400, Richard Kenner wrote:
>   /* If the value is invariant, then there's nothing to pre-evaluate.
>      But ensure it doesn't have any side-effects since a SAVE_EXPR is
>      invariant but has side effects and might contain a reference to
>      the object we're initializing.  */
>   if (TREE_INVARIANT (*expr_p) && !TREE_SIDE_EFFECTS (*expr_p))

Grr.  I guess this is ok for now.

I'm thinking it's a big mistake for SAVE_EXPR to have TREE_INVARIANT set.
TREE_INVARIANT should mean "valid anywhere in the current function".  But
for SAVE_EXPR that isn't so -- it's only valid in places post-dominated
by its first evaluation.  A significant difference in my opinion.

Hum.  I suppose the places it's used at present are for ADDR_EXPR,
SAVE_EXPR, and stabilize_reference_1.  I'll have to give this some
thought.  Perhaps I would be happier with this bit renamed to
TREE_STABLE_P or something.

Please commit the patch with the grammer nit mentioned elsewhere fixed.


r~