The problem is that HJL's patch in 2011 to try and fix his miscompiling of x32
ld.so was in fact incorrect and causes problems with AARCH64 ILP32.
The testcase which is being miscompiled after HJL's patch (which he was also
trying to fix up with his patch on x32):
void f(int *a, int b, long long d) __attribute__((noinline,noclone));
void f(int *a, int b, long long d)
{
if((0x6ffffeff - b) < 11)
a[(0x6ffffeff - b) +34+0+16+3+12] = d;
}
int main(void)
{
int *d = (int*)(int)0xfffefe90;
f(d, 0x6ffffeff, -1);
if (d[34+0+16+3+12] != -1)
__builtin_abort();
__builtin_printf("Works.\n");
return 0;
}
--- CUT ---
The tree level in optimized for AARCH64 looks like:
_72 = _48 * 4294967292;
_73 = _72 + 3221224704;
_74 = &MEM[(struct link_map *)&FRAME.21].l_info + _73;
*_74 = dyn_15;
Expand then comes along and does not the addition with a zero extend so we
get the following AARCH64 assembly code:
madd w2, w2, w6, w0
mov x0, -1073741825
movk x0, 0xfac8, lsl 0
str w3, [x2, x0]
Notice how we have an addition inside the store, since the address will
overflow we get the incorrect address where the store is happening (the
address would have the 33rd bit set).
These two patches have been tested on aarch64-linux-gnu (including testing
with ILP32 multi-lib) with no regression.
The first patch reverts HJL's patch and the second one fixes the issue
which HJL was trying to fix in the first place; I will explain how
in the email with the patch.
Thanks,
Andrew Pinski
Andrew Pinski (2):
Revert: 2011-08-19 H.J. Lu <hongjiu...@intel.com>
Fix ILP32 ld.so.
gcc/explow.c | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
--
1.7.2.5
