blob: 1d3980414658e888deadc8c2df0823e1c405302a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, let's try to figure out what category this QEMU bug falls into. The user is saying that QEMU's PPC emulator (qemu-ppc) incorrectly converts a float NaN to a double that isn't a NaN. They provided a test case where comparing two NaN floats in QEMU gives a different result than on real hardware.
First, I need to understand what's happening here. The problem is about floating-point handling. The user says that when converting a float (which is a NaN) to a double, QEMU is producing a non-NaN double. On real hardware, converting a float NaN to a double should preserve the NaN. The test case shows that QEMU's result is a normalized number instead of a NaN.
Now, looking at the categories: instruction, syscall, or runtime.
An "instruction" category bug would be if QEMU is incorrectly emulating a specific CPU instruction. Since this is about floating-point conversion, which is handled by the CPU's instruction set, it's possible that the QEMU emulator for PowerPC isn't correctly implementing the instruction that converts a single-precision float to double-precision.
The "syscall" category is for system call errors. This doesn't seem to involve system calls; it's about the user-space floating-point operations. So probably not syscall.
The "runtime" category is for other runtime errors. But the problem here is in the emulation of the CPU instructions, which is a core part of QEMU. Since the issue is about how the emulator handles a specific instruction (float to double conversion), it's more likely an instruction-level bug.
Therefore, the classification should be "instruction".
</think>
instruction
|