This is the mail archive of the gcc-help@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: Optimization issue


On Mon, 27 Nov 2017, Juan Cabrera wrote:

Hello,

I think I found a small optimization issue by mistake while checking
the generated assembly code for a function that was using `memcpy`.

Here's the smallest example showing the issue: https://godbolt.org/g/xTn4bZ

When I put a 1 (instead of sizeof int) on the third parameter of
std::memcpy() the resulting code stores the byte on the stack and then
reads it back before returning from the function, (clang doesn't seem
to have the issue)

int read(const void* buffer)
{
   int r;
   std::memcpy(&r, buffer, 1);
   // std::memcpy(&r, buffer, sizeof(r));
   return r;
}

This generates the following code (GCC 7.2):

read(void const*):
   movzx eax, BYTE PTR [rdi]
   mov BYTE PTR [rsp-4], al
   mov eax, DWORD PTR [rsp-4]
   ret

While clang 5.0.0 generates the following:

read(void const*):
   movzx eax, byte ptr [rdi]
   ret

(Both compiled with -O3)


Do you think there's a reason for this or is this just an optimizer bug?

Please file enhancement requests in bugzilla.

  MEM[(char * {ref-all})&r] = _4;
  _6 = r;

Maybe using BIT_INSERT_EXPR would be a nice intermediate step to help notice that we can just zero-extend _4?

--
Marc Glisse


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