blob: a29259f85b3599b6a4e4d63516b2d7b79a22b229 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm looking at this bug report regarding QEMU's handling of RISC-V dynamic rounding modes. The user is saying that the current implementation doesn't update the rounding mode correctly when rm is 7 (the dynamic case) and the frm value changes between instruction executions.
Looking at the code snippet provided, the function gen_set_rm checks if the current ctx->frm is equal to rm. If they are the same, it returns without doing anything. This means that if the rm is set to 7 multiple times with different frm values, the rounding mode isn't updated beyond the first time because ctx->frm remains 7.
In the test case described, when the instruction with rm=7 is executed for the first time, the frm is correctly set because it's changing from whatever it was before. However, on subsequent executions where the frm has changed but rm is still 7, the code doesn't update the rounding mode again, leading to incorrect behavior.
Now, considering whether this is a user-mode or system-mode issue: RISC-V instructions and their execution context are handled in user-mode when running unprivileged code. The fcsr register and its manipulation fall under user-level operations since they don't involve privileged instructions or system resources beyond the CPU state. Therefore, this bug is related to how QEMU handles user-mode instructions and their side effects on the CPU's floating-point unit.
</think>
The issue pertains to how QEMU handles RISC-V floating-point rounding modes in user-mode code execution.
user
|