3 This is a regression test for the following problem, noticed by
6 vex ppc64 generates bad code for instruction sequences like this:
11 gcc emits code like this when manipulating packed structures
12 with 8-byte fields on 2-byte boundaries.
14 First, vex's optimizer substitutes a constant 0x2 for r0:
16 ------ IMark(0x100000F34, 4) ------
17 PUT(1024) = 0x100000F34:I64
20 t13 = Add64(t14,0x2:I64)
23 Then instruction selection chooses `std` with an index not divisible by 4:
25 -- STbe(Add64(GET:I64(8),0x2:I64)) = GET:I64(24)
30 Finally, the assembler silently strips the index&3 part,
31 because `std` can't encode that:
36 ...but 0xF8C50000 is `std r6, 0(r5)`, which writes to the wrong address.
44 struct __attribute__ ((__packed__
)) {
46 unsigned long long int w64
;
51 void foo (T
* t
, unsigned long long int w
)
55 : : "b"(w
), "b"(t
), "b"(2) : "memory"
64 assert(sizeof(T
) == 16);
65 t
= calloc(sizeof(T
),1);
67 /* check t is 8-aligned. This causes the write done by 'foo' to be
68 misaligned by 2 as desired, triggering the bug. */
69 assert(0 == (((unsigned long)t
) & 7));
70 foo(t
, 0x1122334455667788);
71 p
= (unsigned char*)t
;
72 for (i
= 0; i
< 16; i
++)
76 printf("%02x", (int)p
[i
]);