This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH: PR 16405


On Thu, 23 Dec 2004 10:56:14 -0800, Mark Mitchell <mark@codesourcery.com> wrote:

> Jason Merrill wrote:
>> On Thu, 23 Dec 2004 00:12:45 -0800, Mark Mitchell <mark@codesourcery.com> 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?

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]