blob: db22962cbb2e56c0c1d3a8967216c6dfd52e2046 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
The issue lies within the implementation of the FMOPA/FMOPS instructions in QEMU's AArch64 TCG helper functions. Specifically, the problem arises from an invalid pointer being used for floating-point status when handling 32-bit operands, leading to incorrect NaN generation.
Step-by-step explanation:
1. **Bug Identification**:
- The `sme_fmopa_s` function in `target/arm/tcg/sme_helper.c` is responsible for matrix multiplication and accumulation.
- When performing 32-bit floating-point operations, the function incorrectly uses an invalid pointer (`vst`) instead of a properly initialized local copy (`fpst`) to handle the floating-point status.
2. **Consequences**:
- This misuse causes NaN results not to be generated as default NaNs but instead retain their non-default form.
- The test case provided demonstrates this by expecting default NaNs (0x0000c07f) but receiving non-default NaNs (0xffffffff).
3. **Solution**:
- Modify the function to use `&fpst` instead of `vst` when invoking `float32_muladd`.
- This ensures that the correct floating-point status is used, leading to proper default NaN generation.
4. **Category Classification**:
- The issue pertains directly to an instruction's implementation within QEMU, making it a clear case of an **instruction** bug.
The problem is classified under the **instruction** category because it involves incorrect behavior in implementing specific CPU instructions (FMOPA/FMOPS) within the QEMU emulator.
|