This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __builtin_memcpy and alignment assumptions
- From: <Paul_Koning at Dell dot com>
- To: <jakub at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 8 Jan 2016 15:28:53 +0000
- Subject: Re: __builtin_memcpy and alignment assumptions
- Authentication-results: sourceware.org; auth=none
- References: <5e991791-a201-4b8d-89fd-78db873368c7 at BAMAIL02 dot ba dot imgtec dot org> <CAFiYyc3yPAusG2eqw5KoC2eEFBbJyP=ovGGytCYnfG9X4t=S3g at mail dot gmail dot com> <1482639 dot JCa9WsCs7z at polaris> <20160108113220 dot GT18720 at tucnak dot redhat dot com>
> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek <jakub@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