blob: 7583714a76b2252d32a031734de4f529b82ac265 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to classify this bug report as either 'user-mode' or 'system-mode'. Let me read through the details carefully.
The issue is about a refactor in the softfloat code affecting the TriCore ftoi instructions. The helper function int32_to_float32 was changed and now behaves differently. Specifically, it's causing problems with how NaNs and infinities are handled, which affects the helper_ftoi() function in target/tricore/fpu_helper.c.
I know that softfloat is part of QEMU, which handles floating-point operations in user-space emulations. TriCore is a CPU architecture, so this likely relates to how QEMU emulates its FPU instructions for user programs.
The problem arises because the refactored code doesn't raise the invalid flag correctly when dealing with NaNs or infinities, leading to incorrect return values (like returning 0 instead of handling them properly). This seems like it's affecting the execution of user applications running under QEMU.
Since this is about how floating-point instructions are handled in the emulator for a specific CPU target, it falls under user-mode emulation. User-mode deals with application-level issues and instruction emulations without involving higher privilege levels or device drivers.
I don't see any mention of system calls, peripherals, or OS interactions here. It's purely about the FPU operations and how they're being handled in the emulator for user programs.
So, I think this bug is related to user-mode.
</think>
user
|