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.
