This is the mail archive of the
mailing list for the GCC project.
Re: __builtin_memcpy and alignment assumptions
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, Steve Ellcey <sellcey at imgtec dot com>
- Date: Fri, 8 Jan 2016 12:33:14 +0100
- 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>
On Fri, Jan 8, 2016 at 12:24 PM, Eric Botcazou <firstname.lastname@example.org> 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.
As the GIMPLE type system treats all pointer types equal (independet
"random" types may end up in the actual arguments of the memcpy (because what
matters is the pointer value, not the type). In practice this is of
course usually one
of the types in an original conversion chain and thus "fine" if the
source language is C.
I don't see that it should be dependent on strict-alignment or not
of interpreting source language semantics are bad for portability).
In the middle-end (including RTL) alignment is on memory references
and the issue
with things like memcpy is that it is not treated as "memory
reference" with explicitely
I doubt "used to do it" has applied to say
void foo (int *p)
if (p & ~3)
> Eric Botcazou