http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454
--- Comment #2 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-11-25 18:18:16 UTC --- (In reply to comment #1) > Besides from whether the testcase is valid According to http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html "packed - This attribute, attached to struct or union type definition, specifies that each member (other than zero-width bit-fields) of the structure or union is placed to minimize the memory required. When attached to an enum definition, it indicates that the smallest integral type should be used." Is it safe to assume that the size of this "foo" struct is always expected to be 17 bytes in the testcase? If yes, then it must be safe to use any alignment for this struct because an array of "foo" will have elements with addresses at any possible alignments. As such, any memory location can be safely casted to foo* and used. Is there anything wrong with these assumptions? But in fact what I want is just to somehow tell gcc that I'm going to write this vector data type at an unaligned memory location. For example, x86 SSE2 and ARM NEON have unaligned load/store instructions. PPC Altivec can't do it easily, but that's a headache for GCC and the application developer (me) should not care. After all, if running out of options, one can always use memcpy(buffer + 10, a, sizeof(*a)); instead of ((foo *)(buffer + 9))->data = *a; The performance goes down the toilet though. Which would be in fact an acceptable solution for PPC, but x86 and ARM can definitely do much better. > 4.8 should do a better job here. Thanks, I'll check GCC 4.8 a bit later.
