Order of memory accesses not preserved upon emission of `if` statements

[yangzao]

Original code:

      switch(i_l){
        case 0:
            i_l = 15;
            break;
        case 1:
            s_l = 456;
            break;
        case 2:
            str_l = str_l_alt;
            break;
        default:
            l_l = 9876543;
            break;
        }

Decompiled code:

  if (_stack._offset_12 == 1) {
    _stack._offset_32 = _stack._offset_40;      // str_l = str_l_alt; (case 2)
  } else {
    if ((int32_t) _stack._offset_12 > (int32_t) 1 && (int32_t) _stack._offset_12 < (int32_t) 2147483646) {
     
      _stack._offset_24 = 9876543;                 // l_l = 9876543; (default)
    } else {
      switch (_stack._offset_12) {
        case 4294967295:
        {
          _stack._offset_12 = 15;                     //  i_l = 15; (case 0)
        } break;
        case 0:
        {
          _stack._offset_10 = 456;                   // s_l = 456; (case 1)
        } break;
        default:
        {
          _stack._offset_24 = 9876543;
        } break;
      }
    }
  }

Description:
Before this code snippet, variable i_l is 2, so case 2 should be executed.

In the decompiled code, the first if body comes from the original case 2 body, so the condition is supposed to be _stack._offset_12 == 2. But it is recovered as == 1, so the if body is not reached.
Instead, the second if condition is met and the code corresponding to original default body is executed.

Files:
1.zip
(original code orig.c, original exec orig_exec, PTML file dec.ptml, and decompiled code dec_default.c are included)
Reproduce the issue:

1. compiled orig.c with GCC and -O0.
2. decompile the program with rev.ng into C code.
3. this issue is in func_1() near the end of decompiled code.

[aleclearmind]

The IR looks like this:

  %16 = load i32, ptr %3
  %17 = add i32 %16, 1
  store i32 %17, ptr %3
  %18 = icmp eq i32 %17, 2
  br i1 %18,

The IR is correct. I think there's something wrong in MarkForAssignments.
Assigning this to @pfez and moving to revng-c.

[pfez]

This pull request should fix it #19

I'm running a few more tests locally and I'll merge it within tonight.

Please let me know if it works for you

[pfez]

#19 was merged.

Closing this, since it should now be fixed.