Fixing '__asm' in pseudocode in IDA PRO (inconsistent fpu stack error)

Question

So I was doing some REing in IDA, changed a function parameter type and suddenly my stack pointer messes up (1025B361: inconsistent fpu stack). Does anyone know what to look for here or how to fix it?

I tried the following:

• Undefining-redefining and changing argument types.
• Changing the `double game_time` type to `float` in pseudocode, but it won't let me (`Sorry, cannot change variable type`, because it's in use in the pseudocode).
• Changing the stack definition from `0000018C var_18C dq ?` to `dd`.
• Changing the signature of `director_debug`.
• Manually editing the HEX code from `DD 1C 24` to `D9 1C 24` (forcing m32fp).
• In order: changing the function signature, changing the stack value, undefining the calling function and redefining it as a function (code).

However, none of this helped.

Pseudocode

_EDX = game_time_ptr_12; //float edx@2
__asm
{
  fld     dword ptr [edx+0Ch]
  fstp    [esp+18Ch+var_18C]
}
director_debug("%3.2f: Director debug: %s.\n", *(_QWORD *)&game_time, "NORMAL MODE"); //double||__int64 game_time ST24 8@2

Dissassembly

.text:1025B35B 0 184                 mov     edx, game_time_ptr_12
.text:1025B361 0 184                 fld     dword ptr [edx+0Ch]
.text:1025B364 1 184                 push    offset aNormalMode ; "NORMAL MODE"
.text:1025B369 1 188                 sub     esp, 8
.text:1025B36C 1 190                 fstp    [esp+18Ch+var_18C] ;qword ptr [esp]
.text:1025B36F 0 190                 push    offset a3_2fDirectorDe ; "%3.2f: Director debug: %s.\n"
.text:1025B374 0 194                 call    director_debug

What it should become

game_time = *(game_time_ptr_12) + 12);
director_debug("%3.2f: Director debug: %s.\n", game_time, "NORMAL MODE");

Answer 1

In the Disassembly view, click "Edit → Other → Reset decompiler type information" and then select most or all of the checkboxes and hit "Ok."

I did that to repair some register variables I accidentally combined into a double and then couldn't separate them again.

Answer 2

I recently had the very same issue and I could only fix it by checking the following:

Whenever some methods returned float or double, calling methods displayed __asm fstp instructions instead of pseudo code assignments despite those method's stack being seemingly well defined. Additionally, inconsistent fpu stack is displayed in the Output window when listing these methods.

Switch to the disassembly of a messed up method. Its address line prefixes are accompanied by (what seems to be) the problematic FPU stack pointer. It will display a negative value (like .text:0x0065789-1) at locations it calls methods that should return float or double.

I double-checked the return types of those methods, switching them back and forth from int to float/double, which eventually fixed the decompilation of the calling methods again.