On Tue, May 05, 2015 at 12:01:59PM +0100, Richard Earnshaw wrote:
> > Either way, this would need careful cross-testing against an existing
> > compiler.
> >
>
> It looks as though either patch would cause ABI incompatibility for
>
> typedef int alignedint __attribute__((aligned((8))));
>
> int __attribute__((weak)) foo (int a, alignedint b)
> {return b;}
>
> void bar (alignedint x)
> {
> foo (1, x);
> }
>
> Where currently gcc uses r2 as the argument register for b in foo.
That is true, but as you can't call it with almost anything else:
void bar2 (alignedint x)
{
foo (1, (alignedint) 1);
}
void bar3 (alignedint x)
{
foo (1, x + (alignedint) 1);
}
alignedint q;
void bar4 (alignedint x)
{
foo (1, q);
}
eextern int baz (int, int);
void bar5 (alignedint x)
{
baz (1, x);
}
is all broken, I'd seriously doubt anybody is actually using it
successfully.
Having an ABI feature that most of the time doesn't work at
all, and occassionally happens to work, is just unsupportable.
You could add a -Wpsabi warning in the callee, warning if any of the
non-aggregate arguments has
TYPE_ALIGN (type) != TYPE_ALIGN (TYPE_MAIN_VARIANT (type))
to let users know that this really didn't work in <= 5.1.
And supposedly we need the tree-sra.c patch then so that eipa_sra
doesn't create the over-aligned parameters, because -Wpsabi then would warn
about those.
In any case, this is a P1 issue that needs resolving RSN, not just on the
trunk, but also on the branch, and the tree-sra.c patch I've posted isn't
anywhere close to resolving it without fixing the backend.
I'm in the middle of bootstrapping/regtesting this on armv7hl (both
profiledbootstrap to see if it fixes it and normal one).
Jakub
