blob: 84432a6c9f464c6eb6b5e43576046e4b998834e0 (
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
|
device: 0.591
performance: 0.553
ppc: 0.537
architecture: 0.439
semantic: 0.431
permissions: 0.377
vnc: 0.370
virtual: 0.369
PID: 0.348
socket: 0.318
register: 0.316
graphic: 0.307
files: 0.288
debug: 0.280
network: 0.259
TCG: 0.240
user-level: 0.227
assembly: 0.216
risc-v: 0.214
peripherals: 0.209
x86: 0.194
arm: 0.174
VMM: 0.152
hypervisor: 0.120
kernel: 0.110
mistranslation: 0.102
i386: 0.094
boot: 0.083
KVM: 0.042
ppc64le: possible SIMD issue casting double to int
Description of problem:
Working with numpy in a ppc64le VM, I ran into a strange double -to casting issue, specifically when casting an array of 1.0 values to 1 values. The numpy folks guided me to a small reproducible test case.
The attached [convert.c](/uploads/2dd7936f4defccf816ffee7c7c002e77/convert.c) creates double and int arrays of length `1 <= n <= 16`. The double array is filled with the value 1.0, and both arrays are passed to a function that converts the value.
With `-O2`, output is as expected (truncated here):
```
i = 1: 1
i = 2: 1 1
i = 3: 1 1 1
i = 4: 1 1 1 1
i = 5: 1 1 1 1 1
i = 6: 1 1 1 1 1 1
```
With `-O3`, all values that fit into blocks of four become zero:
```
i = 1: 1
i = 2: 1 1
i = 3: 1 1 1
i = 4: 0 0 0 0
i = 5: 0 0 0 0 1
i = 6: 0 0 0 0 1 1
```
I tested this with executables compiled on a physical ppc64le host, where the issue is not reproducible.
Steps to reproduce:
1. `gcc -O2 -o convert convert.c && ./convert`
2. `gcc -O3 -o convert convert.c && ./convert`
|