Re: Structure Return Testcase

[Jeffrey A Law <law at redhat dot com>]

  In message <20010315155740S.mitchell@codesourcery.com>you write:
  > This is the key philosophical question: to be conservative here, or
  > not.
  > 
  > Jeff suggested that we be conservative -- until we have a chance to
  > find the places where we don't need to be, which certainly include
  > ordinary assignment expressions in C-like front-ends.  The alternative
  > (your suggestion) is to be aggressive -- since we've been broken
  > before in this respect, continue to be broken, and try to find the
  > places that introduce the brokenness and fix them there.
  > 
  > The reason I think a bit (rather than a new code) is a good idea is
  > that almost all of the handling of such an expression is the same as
  > for a MODIFY_EXPR -- the only difference is that if you can't
  > atomically move the storage, then you do something different.  So, by
  > not adding a code we avoid having to change a bazillion case
  > statements to handle COPY_EXPR, and treat it just like MODIFY_EXPR.
The one problem I see with the way we seem to be heading (either a bit
in MODIFY_EXPR or a new tree code) is that we don't have access to that
info when we actually need it.  ie, inside expand_assignment.

It seems to me that if we're going to have modifiers on how we perform
assignments that we'll want to to have those semantics bits in the tree
structure itself (or as a different tree code), rather than passing them
as separate out of line arguments.  It just seems to me that the more
accurate our tree structure is about what's going on, the better.


That would (of course) be an interface change and it appears that the
usage of expand_assignment has bled into front-ends in the past
(chill, java).

So I'm pondering creating something like expand_modify_expr which looks a
lot like expand_assignment does now, except that it's passed the actual
assignment expression instead of the lhs & rhs args separately.

expand_assignment would then be changed to just cons up a trivial
MODIFY_EXPR expression and pass it off to expand_modify_expr.

[ Separately, I'd like to see the expand_assignment interface go away,
  which means doing some front-end updates. ]

Thoughts?

jeff