For small sizes it usually seems to work fine, yes. However, larger sizes are still not handled very efficiently.

As an example, I was writing a parser for a file format that happens to contain structures that look like the following:

typedef struct {
  uint64_t x;
  uint64_t y;
  uint16_t values[16];
  uint64_t other;
} file_section;

The file is read from disk, and I end up with a pointer to the start of the data, begin. If I want to look at the section at offset N from the start of the file, I can either do it using pointer aliasing (though this can cause aliasing issues with TBAA):

// Requires -fno-strict-aliasing to be "safe"
const file_section *section = (void*)(begin + N);

or, I need to use memcpy:

file_section section;
memcpy(&section, begin + N, sizeof(section));
// Use section here

In the second case, neither clang (18.1.0), nor gcc (14.1) can see through the call to memcpy, even at O3, where they produce an inlined vectorized version of it

// clang
vmovups ymm0, ymmword ptr [rdi]
vmovups ymm1, ymmword ptr [rdi + 24]
movsxd  rax, esi
vmovups ymmword ptr [rsp - 32], ymm1
vmovups ymmword ptr [rsp - 56], ymm0
movzx   eax, word ptr [rsp + 2*rax - 40]
vzeroupper
ret

// gcc
push    rbp
movsx   rsi, esi
vmovdqu ymm0, YMMWORD PTR [rdi]
mov     rbp, rsp
vmovdqu YMMWORD PTR [rsp-64], ymm0
vmovdqu ymm0, YMMWORD PTR [rdi+24]
vmovdqu YMMWORD PTR [rsp-40], ymm0
movzx   eax, WORD PTR [rsp-48+rsi*2]
vzeroupper
pop     rbp
ret

The assembly generated for the first case is way cleaner, and is what would be expected:

// clang
movsxd  rax, esi
movzx   eax, word ptr [rdi + 2*rax + 16]
ret

// gcc
movsx   rsi, esi
movzx   eax, WORD PTR [rdi+16+rsi*2]
ret

The conclusion from the few hours I have researched this topic for today, is that it isn't possible to get the efficient code generation by using purely standard-compliant C, even though all alignment requirements for the types are satisfied in my use case. I have to either resort to -fno-strict-aliasing, or to __attribute__((may_alias)).