http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #7 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> 2010-12-02
16:42:40 UTC ---
(In reply to comment #6)
...
< , as an example look at the types the C frontend
> generates for struct X __attribute__((packed)) { int x; };
> void foo (struct X *p, int *q) { memcpy(&p->x, q, 4); } - &p->x
> will have int * type, not int aligned(1) * type.
...
> I considered infering initial alignment from function argument pointers
> pointed-to types. But I think that's still dangerous. Also alignment
> can be infered from dereferences, but that doesn't easily fit into the
> CCP framework (there's no def for the pointer) and is also dangerous
> as there is a lot of code out there that simply assumes misaligned
> accesses are ok.
>
> In short, it's not easy. I'd consider the pointer argument thing
> for 4.6,
Do I understand correctly that alignment of &p->x from the above example can be
correctly inferred from argument 'p'?
> but would it really help in practice (as opposed to
> simple artificial testcases)?
The above example was reduced from Dalvik VM, used in Android, and, generally,
expanding __builtin_memcpy and company to 4-byte loads/stores instead of 1-byte
loads/store is a problem worth fixing.
>From the front-end point of view, are there any inherit problems that prevent
front-ends setting reliable alignment information on the types that middle-end
could trust? The information is there, right? It's just that middle-end
cannot trust it due to several unfortunate instances when front-end sets it
wrong.
