> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote:
>>> See some existing PR. The GCC middle-end cannot assume that pointers
>>> are aligned according to their type (while at least the C language would
>>> support that notion).
>>
>> Only on x86. It could (and used to) do it on strict-alignment architectures.
>
> I think we only assume it if the pointer is actually dereferenced, otherwise
> it just breaks too much code in the wild. And while memcpy dereferences, it
> dereferences it through a char * cast, and thus only the minimum alignment
> is assumed.
Is the char* cast actually part of the definition of memcpy?
The fact that memcpy doesn't make use of the known alignment is a rather
unfortunate issue (I'd call it a defect); it results in clearly inferior code
on strict-alignment machines when the alignment is in fact clearly known.
If it really is necessary to say that memcpy is defined to behave as if it had
a cast to char* in its implementation, it would still be useful -- and
obviously valid -- to rely on the greater alignment when there is other code in
the block that uses it. And it would be helpful to have a way in the source
program to say "I want you to rely on the type alignment".
paul
