Ping.
On Fri, Aug 8, 2014 at 8:51 PM, Andrew Pinski <apin...@cavium.com> wrote:
> 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
>
