1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<think>
Okay, let's see. The user provided a bug report related to PowerPC AltiVec and Rust code. The problem is about subnormal values not being flushed to zero as specified. The code uses AltiVec intrinsics, and the issue is that the source vectors aren't flushed, only the results. The assertions fail because of this.
The question is to classify this bug into one of the categories: instruction, syscall, or runtime. The user says it's part of QEMU.
First, I need to figure out what's causing the issue. The problem is with how AltiVec handles subnormal numbers. The Rust code is using vec_splats and vec_add, which are intrinsics. The bug is that the source vectors (the inputs) aren't being flushed to zero in NJ mode. According to the AltiVec spec, both source and result vectors should be flushed, but in reality, only the result is.
So when the code runs, adding a very small subnormal value (-1.08e-38) and 0.0, if the source is flushed, the result would be 0. But since it's not, the result is -0.0, leading to the assertion failure.
Now, why is this happening? If the code is compiled with Rust's stdsimd and powerpc_target_feature, the issue could be in how the intrinsics are implemented in the compiler (Rust) or in the QEMU emulator when executing the PowerPC instructions.
But the user says it's part of QEMU. So maybe QEMU's emulation of the AltiVec instructions isn't correctly handling the flushing of subnormal source vectors. If the real hardware flushes the source vectors, but QEMU doesn't, then when the code runs under QEMU (like in a simulation or virtual machine), it would fail.
The classification options are instruction, syscall, or runtime.
If the problem is that QEMU's implementation of a specific instruction (like vec_splats or vec_add) isn't following the AltiVec spec regarding flushing subnormals, then this would be an instruction-level error. Because it's about how a particular instruction is emulated.
Syscall would be if the issue involved system calls, which it doesn't here. Runtime might refer to the Rust runtime or something else, but the problem seems to be in the execution of the machine instructions, which is QEMU's job.
Therefore, since the issue is in how QEMU emulates the AltiVec instructions, the category is "instruction".
</think>
instruction
|