Starting with gcc 10, the following code (based on https://github.com/ebiggers/libdeflate/blob/v1.5/lib/decompress_template.h#L353) isn't compiled as expected at -O3 on x86_64:


#include <stddef.h>
#include <stdio.h>

#define WORDSIZE	sizeof(size_t)

struct word_unaligned {
	size_t x;
} __attribute__((packed, may_alias));

static inline size_t load_word_unaligned(const char *p)
{
	return ((struct word_unaligned *)p)->x;
}

static inline void store_word_unaligned(size_t x, char *p)
{
	((struct word_unaligned *)p)->x = x;
}

void __attribute__((noinline))
copy(char *dst, const char *src, size_t word_count)
{
	do {
		store_word_unaligned(load_word_unaligned(src), dst);
		src += WORDSIZE;
		dst += WORDSIZE;
	} while (--word_count);
}

int main()
{
	char buf[9 + 6 * WORDSIZE + 1] = "012345678";

	copy(&buf[9], &buf[0], 6);

	puts(buf);
}


The code is supposed to copy 6 eight-byte words from &buf[0] to &buf[9], one word at a time, resulting in the output "012345678012345678012345678012345678012345678012345678012".  But the actual output is "012345678012345678".  Based on the diassembly, this seems to be caused by gcc assuming that the src and dst pointers are offset from each other by a multiple of 8 bytes.  It uses this assumption to generate 16-byte-at-a-time SSE copy code.  But that's invalid when the pointers are actually offset by 9 bytes as in the example.

Is this working as intended?  I don't think so, since the use of packed and may_alias should make gcc assume that the pointers can have any alignment, and each store can alias the next load.  But perhaps there's some reason I'm missing why the code could nevertheless be considered incorrect, or perhaps there's some ambiguity in what 'packed' is supposed to do (it's a gcc extension after all).

I'm going to change my code to use memcpy() anyway, since the bugs where gcc generated bad code for memcpy() in some cases have supposedly been fixed in recent gcc's.  But I thought I'd point this out since I'm not sure it's working as intended, and probably other people will run into it too.  Decompression code is most likely to be affected by this.

gcc 9.3.0 works fine.  I didn't test anything in between that and 10.1.