1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
performance: 0.915
semantic: 0.886
other: 0.830
graphic: 0.817
device: 0.770
debug: 0.745
PID: 0.661
permissions: 0.647
network: 0.646
vnc: 0.567
files: 0.558
socket: 0.540
KVM: 0.539
boot: 0.473
RISCV64 32-bit AMOs incorrectly simulated
Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14)
test:
amomaxu.w a0, a1, (a0)
ret
int32_t* value = -7;
EXPECT_EQ(-7, test(&value, -11));
EXPECT_EQ(-7, value); // FAIL, saw -11
EXPECT_EQ(-7, test(&value, -7));
EXPECT_EQ(-7, value); // FAIL, raw -11
EXPECT_EQ(-7, test(&value, -4));
EXPECT_EQ(-4, value);
test:
amomax.w a0, a1, (a0)
ret
int32_t* value = -7;
EXPECT_EQ(-7, test(&value, -11));
EXPECT_EQ(-7, value);
EXPECT_EQ(-7, test(&value, -7));
EXPECT_EQ(-7, value);
EXPECT_EQ(-7, test(&value, -4));
EXPECT_EQ(-4, value); // FAIL, saw -7
I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl.
Not as simple as _tl vs _i32. That suffix should be taking
care of the sign-extension to _tl that happens after the
operation. The size of the operation should be in the MO_TESL,
which specifies target-endian signed "long" (32-bit).
Will investigate further.
Flushing out the report to something that compiles,
the test case works for me using qemu 5.2.
|