This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH: PR 16405
On Thu, 23 Dec 2004 10:56:14 -0800, Mark Mitchell <email@example.com> wrote:
> Jason Merrill wrote:
>> On Thu, 23 Dec 2004 00:12:45 -0800, Mark Mitchell <firstname.lastname@example.org> wrote:
>>>This patch fixes a C++ optimization problem. In the case of the code
>>>in the attached test case, the compiler was generating a temporary for
>>>"a + b", as expected. Then, for the call to the (implicitly declared)
>>>assignment operator "T::operator=", we generated another temporary, to
>>>bind to the const reference parameter to the assignment operator.
>>>That's permitted, but silly.
>>>The problem was that the front-end generates:
>>> memcpy (&a, *(const T*)&<target_expr operator+(b, c)>, sizeof (T))
>>>The gimplifier could not see through the INDIRECT_REF/ADDR_EXPR
>>>combination to find the underlying TARGET_EXPR, and so generate a
>>>temporary for it.
>> I don't see where the second temporary you mention is coming from. I
>> would expect the gimplifier to generate a temporary to store the address
>> of the TARGET_EXPR temporary, but that's just a scalar.
> The result of operator+ is a class object, not a scalar. The TARGET_EXPR
> contains the result of the call to operator+.
Yes, that's the first, expected temporary. Where's the second?