blob: 005765f117dc87004dcc91a647da34fa85c6d71f (
plain) (
blame)
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
ppc: 0.978
architecture: 0.922
device: 0.844
graphic: 0.800
performance: 0.728
network: 0.626
mistranslation: 0.585
files: 0.571
peripherals: 0.555
user-level: 0.503
arm: 0.498
risc-v: 0.483
semantic: 0.478
kernel: 0.476
socket: 0.448
boot: 0.419
debug: 0.405
vnc: 0.387
VMM: 0.347
PID: 0.253
TCG: 0.239
permissions: 0.205
KVM: 0.186
virtual: 0.156
register: 0.140
i386: 0.111
hypervisor: 0.107
assembly: 0.065
x86: 0.011
--------------------
ppc: 0.999
debug: 0.673
user-level: 0.663
TCG: 0.130
files: 0.055
architecture: 0.042
virtual: 0.039
assembly: 0.032
hypervisor: 0.032
register: 0.032
kernel: 0.027
performance: 0.023
network: 0.020
PID: 0.015
semantic: 0.012
peripherals: 0.010
device: 0.006
VMM: 0.004
socket: 0.002
graphic: 0.001
permissions: 0.001
boot: 0.001
vnc: 0.001
KVM: 0.001
risc-v: 0.001
mistranslation: 0.001
arm: 0.000
x86: 0.000
i386: 0.000
PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped
When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions:
If the binary contains vrfim QEMU sees vrfiz
If the binary contains vrfin QEMU sees vrfim
If the binary contains vrfiz QEMU sees vrfin
The vrfip instruction is correctly recognized.
Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n).
This problem should have been fixed by the following commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=abe60a439b760c749201
... so closing this ticket now.
|