blob: 1515f389ff6bd7b0075276f071bcb0f3c66f58e6 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, I need to figure out whether this RISC-V froundnx.h instruction bug is related to user-mode or system-mode in QEMU. Let me start by understanding the problem.
The issue is about a typo in the helper function for the froundnx.h instruction. The current code uses check_nanbox_s instead of check_nanbox_h, which leads to incorrect handling of NaN-boxed values. When an incorrectly boxed value is passed, it should return a canonical NaN but instead returns 0.
Looking at how QEMU handles floating-point operations, these are typically part of the CPU's instruction set and are emulated in user-mode unless they involve system-level instructions like those requiring privileged access or interacting with hardware.
The froundnx.h instruction operates on half-precision floats, which is a standard floating-point operation. The helper function modifies how it handles NaNs but doesn't seem to interact with any system resources like memory, devices, or require higher privileges.
Since the bug is within the CPU's emulation of a specific instruction and doesn't involve system-level operations, it's likely a user-mode issue. User-mode code runs in the application space without needing special privileges, so the problem lies there.
</think>
user
|