Potential fix for rdar://4658012

[Richard Kenner]

Sorry I didn't reply to this earlier.  I was unexpectedly in a place with
very bad network access.

> The one exception to this is if the address of the temp is taken before
> I call pop_temp_slots.  In that instance, even though I may be "done"
> with the temp, it needs to live until the end of the high-level-language
> scope, and so it is marked with addr_taken and is pushed up in the temp
> scopes using preserve_temp_slots.  It is this logic that is used for
> function calls that return a value on the stack.

Right.

> 
> However, in the case where we're passing the address of a temp slot to a
> function, it doesn't make sense to me that this is the same as other
> "address-of" operations on a stack slot.  The function call (at least in
> C and C++) cannot preserve this address, and it is reasonable to say
> that attempts to access this address after the caller is done with the
> location, are invalid.

Here's where I disagree.  The issue isn't what the front-ends (and especially
not a *subset* of the front-ends) do, but what they *are allowed* to do.

Going back to 3.4 for a moment, the question is whether you could
create a valid tree where the address would survive.  And I think you can.
All it would take is a machine like Sparc that passes all aggregates by
reference is to have a CALL_EXPR with two operands that are each CALL_EXPRs
of aggregate types.

We never had a precise specification of what trees were valid then (which
is precisely the set of valid GENERIC, and hence is similarly not very
precisely defined), but I think almost everybody working on the 3.4 compiler
would say that the above is valid whether or not C or C++ could generate it.
Therefore, the middle-end had to properly support it.

However, in GCC 4, with tree-ssa, the RTL expanders receive a much smaller
subset of trees, namely those defined in GIMPLE.  I *believe*, but aren't
sure, that the above is not valid GIMPLE.

That would make the change safe.  But:

(1) The code we generate is pretty inefficient in the current case, since we
copy the entire aggregate.  If we try to fix that, we *will* be preserving
the address for later, though perhaps in a temporary more properly allocated.

(2) I suspect that we can rip out much more of this code than just this line
and I'd prefer to do it that way.

> Hopefully this is enough of an explanation to reveal whether my
> understanding is consistent or inconsistent with the experts, and can
> move the discussion forward.

As I said once before, this code didn't change between 3.4 and 4.x, so
something else is the cause of the regression.  I'd like to understand
what that was.  I think you posted the changes you propose for the C
and C++ front ends, but I don't remember what they were.