This is the mail archive of the
mailing list for the GCC project.
Re: Potential fix for rdar://4658012
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.
> 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.